The older guys, they seem like they had the time to correctly learn the unix network tools, the jvm debugging ones, the memory inspection ones. I've known older devs for which I have the utmost respect because I felt like they can just debug the shit out of anything happening on a computer, with tools I don't even know of but have been there for decades.

And here I am, needing to google how use tcpdump or jstack, and scrambling to correctly understand the result.

I agree that new tech is always stacking, but I feel like it's pretty damn hard to catch up on the in fact still very relevant and important old one, because it's no longer taught, no longer a meetup topic, no longer hype. And the new one is really easy to learn when you realize that it's 90% rehashing of old concepts (Observables are all the hype in javascript ? Well, great, I've learnt that pattern 15 years ago...)

Admittedly, I have no clue if the management realizes that !

But the impact of this knowledge, from what I observed, is really huge on productivity, and is especially a boon when the production is on fire or generally when tricky stuff happens.

So, respect for the elders, and please come and teach in conferences and meetups, we need more wisdom and less hype !

In the meantime, though, every single older developer I've met has been extremely knowledgeable and frankly much better at the craft than myself.

Look at any hobby -- say, guitar playing. The difference between someone who's been doing it for 4 years and someone who's been doing it 20 years is ridiculous. They're so much better. I feel software dev isn't that different.

The only problem is if you're older you do need to follow new technologies. Older devs I've talked to who were pushed out of the field are the types who worked on, say, mainframe technology well into the mid-aughts and never thought about learning anything new.

As long as you get off the sinking ship of technologies that are obviously waning (and you should have at least a decade of warning in advance, I think), I don't think it's honestly that hard to stay current. You don't have to follow every fad, but make sure people will continue to use your main programming language.

Also, startups discriminate on age because they need people that can work until 2 AM and drink their Kool Aide. But there's a lot of stable, non-startup jobs out there. People who have never left the scene probably think of it as death, but there's actually some really nice enterprise shops out there with great developers.

I currently work at Wing Aviation, the Alphabet drone delivery company. We were originally located in the Google X building, which is the old Mayfield Mall in Mountain View. I used to shop at that mall in the 1970s!

X is full of hardware startups, and when I started there I noticed one thing right away: for the first time in a while, I was not the oldest person in the building.

Now that we've moved to our own smaller building, I may be the oldest again, but not by a wide margin. There is a lot of gray hair in our teams.

I'm 67 and have been programming for 50 years.

> I'm 67 and have been programming for 50 years.

Also, that's really impressive. You've probably forgotten more than I've ever learned!

In the 80s you needed to understand computer hardware much better and there was a bigger fraction of C++ developers. Now all those people have migrated to hardware (or have kept doing it) because that's where their skills are needed.

I'm not sure how satisfying this is. You probably don't get much chance to dig deep and solve tough problems, or craft as you would in a hardware-oriented job.

I've never worked in hardware though, so I'm quite possibly complete wrong about their day-in-the-life. Just rampant speculation.

You also don't need to get on the ground floor. Every technology boom creates next years legacy apps, there will be React work for years after the next tool gets popular for one example. The article touches on it, but you can make a good living out of consulting work for older technologies.

Another angle is moving into non-tech domain specialization. Becoming an eCommerce consultant, your value proposition isn't knowing React/Shopify/Demandware etc, it's knowing the eCommerce ecosystem and domain. I know devs who specialize in agribusiness, automotive software, construction, energy infrastructure and such. They build solutions to problems in those spaces that happen to be software. But they get hired based on their time in those industries not their current tech stack.

To be fair, this observation could be massively influenced by survivorship bias - more talented devs tend to be the ones still programming in older age.

Now in my country, when you hire someone, a probation period of two months is very common. In that period, you can be fired and/or leave without cause.

Unfortunately, he was not able to pick up object-oriented programming in those two months and left before the probation period expired.

As with flash floods of rivers, the coverage of such events was complex. It probably affected some companies a lot more than others.

Anecdotally, it used to be an aphorism at Microsoft that if you hadn't made your first million by 30 (or was it 25?) you were doing something wrong. Certainly the demographics at Microsoft showed several clear waves of early retirements from stock booms and bonuses, and for a ~forty year old company the median age is still staggeringly young today, even accounting for industry ageism.

If it wasn't clear, I don't expect those flash floods to happen again, they definitely seem to have been flukes of luck. But I think it shouldn't be ignored that it had an impact on the industry demographics.

Google, Amazon, Facebook, Netflix... It already happened again multiple times after Microsoft.

I entered the field in the mid-90s and saw the industry hugely explode at the end of that decade. So as all of those nascent developers look around they noticed how few older developers there were and said "boy, this really is a young person's profession!". I remember all of the "before you turn 30, get a plan B" articles then, everyone fearfully looking into management or dubious project management paths.

And as that cadre aged, of course most new workers are younger, so proportionally they drop from a majority to a minority, but there are a massive number of very gainfully employed, successful older developers, and it certainly has been normalized far more than then.

Sure, you won't be as good as someone that's played flemanco all their life. But if flemanco was invented 5 years ago you're sure going to pick it up fast and probably be better than someone who has only been playing it for the past few years.

Skills translate. Transfer learning is unsurprisingly a real thing. The funny thing is that a guitar player will pick up a brand new instrument and quickly gain and surpass someone who has only been playing that instrument for a few years. Even though each instrument is a different "language" per say, there are common patterns in the language tree of music. I don't think any programmer worth their salt would disagree that this is also true for programming.

No matter the language you use, there are common patterns. Someone who has been programing for years generally picks up a new language quickly (because of this). Certain languages will make you a better programmer in general too (low level languages help you understand what's going on behind the curtain).

So should a programmer with 30 years of experience in C and 1 year in rust be paid more than the programmer with 5 years of rust experience? Absolutely. Those 30 years they were learning to program, to debug, to solve problems. The skills translate. And I say this as someone under 30. I've seen the wizards solve problems in languages they've never used because they just understand programming.

Tell this to HR/recruiting departments.

I'm a highly experienced C developer with some python and JavaScript experience on the side yet can't get any jobs on those as HR/recruiters will just filter my resume out every time due to "insufficient python/JS experience".

HR has no idea how programming skills and experience translate across languages, they're just trained to filter out people based on buzzwords.

On the other side, everybody is looking for people already versed in the languages they need right NOW and aren't gonna take the chance on someone proficient in other languages hoping they'll master the new ones soon enough. Too risky for business.

For example, on my team, we're writing most of our new code in Kotlin. But even though the language has now been around for the better part of a decade, we regard prior Kotlin experience as only a very slight nice-to-have when we're evaluating someone. If you've programmed in Java or Scala or C# or C++ or pretty much any other statically-typed language, you'll pick it up quickly enough that the time to get productive in Kotlin will be dwarfed by the time to get familiar with our code base.

What we do usually filter out, though, is monoglots. If you have 10 years of experience and have only ever done, say, Ruby on Rails development, you will probably not have the breadth of engineering perspective to succeed on our team. But if you've done RoR as well as something else that's dramatically different, that's fine. We would probably even filter out a Kotlin monoglot in the unlikely event we ever came across one.

30 years of experience in C? Would you mind dropping a resume to my username AT google dot com to give me a chance to get referral bonus? :D

As for rails? Admittedly I'm in an anti-ruby bubble... but the Ruby developers I do know definitely don't use Rails anymore. Ruby seems to have matured into basically just Chef/Vagrant in my bubble and any Rails apps are being deprecated in favor of the bubble-biased languages.

What makes you think this? I have been on here for years and have never really got this impression.

- Any thread about rust

- Any thread about an exploit in a c variant

The shelf life is due to a business decision, where the knowledge the older person has is deemed insufficient to justify the compensation they've grown used to.

Sure, you love working with them and it's better for engineering, but the business wants college grads they can pay less, even if they don't do the same quality work.

Importantly, this doesn't have to be logical or good for the business. It just has to make sense in the context of quarterly targets.

As I'm fond of saying, I may cost twice as much as an entry level engineer, but I can do things that two entry level engineers can't do.

I'm working on hiring back into software roles now... I figure if the bar is that low, I can rock it out if I can just convince anyone that I can still code.

Interviews have been interesting.

This isn't typically how it plays out when you start a new job for someone else. Which means they won't reap the rewards of your experience until enough trust has been built to give you the autonomy to make it happen (this may never happen). So it takes time, and not everyone wants to take that time or can see the benefit, and arguably in the startup space there may not be enough runway for it either.

[0] Note, I'm not saying all young developers or all managers. Only a small subset of each.

But then you would have to compete with young people starting out in the same technologies. And they are more naive, more easily manipulated and exploited, corporations love that and prefer that to 20 year experience in the field they can't even understand could be important to all the new technologies.

While this is true for you, there is a lot of selection bias and survivor bias involved in this.

For These older developers you need to also consider their comrades they were working with 20 years ago. For every older dev you work with today, there are 10 of their former buddies that decided long ago they didn’t need to advance beyond VB 6, or IVM mainframe assembler or RPG/3.

But I do think there's a bit of generational shift that the stereotype of outdated engineers haven't caught up with. When I started out in the mid-90s, anyone more than a little older than me didn't have a CS degree and had come up in a world without source control, continuous integration, automated testing, iterative development processes, open source libraries, etc, etc. So in some ways they were from a different planet than the next generation. Although the tech du jour still changes quickly, programmers in their 40s these days still have a comparatively small gap when it comes to education and development process.

There may well be a correlation there, but which is the cause and which is the effect is less clear.

That just means the field isn't totally corrupt with fashion or nepotism or whatever. Survivor Bias is a perfectly plausible explanation, too.

Every single older guitarist I've met has been a fantastically successful rock musician.

I'll do whatever (I am officially a 80% backend dev who can do enough frontend when needed). The Dojo way of writing things actually seems a lot nicer than React, but it ain't cool.

This may seems strange from where you sit but trust me. If you stay in the field that length of time, you will probably become that guy. You don't need to set out to be him. The only thing it requires is time and a refusal to stagnate.

The way to get past this is to make sure you develop skills that are exotic and high-end and hard to find so you can't easily be replaced by a cheaper college grad.

I put a ton of time and thought, and effort into the change. It wasn't easy to complete the transition and get hired, but I settled on C#. Chosen because C# and Java are similar enough (my only formal education in programming was in Java), and I could move between the two, if I had to. I also saw MS driving the future of .Net really hard, even after about 10 years before it looked like there was no future and MS was going back to unmanaged code. I also wanted as stable of a development platform as possible, an attempt at avoiding churn with all the kiddos in the web space. I'm still working fulltime as a C# dev and enjoy it. But if anything ever happens, I'll jump ship to the Java space. Both the city I live in and less-populated state that I'm from have copious amount of C# and Java jobs available, so I'm not on something so cutting edge that I have to live somewhere specific. It's my opinion that the best balance for most software projects was nailed with Java (and then it's descendent, C#). There's a reason it's so popular and they're not bad reasons.

My dream job is to come full circle and be "the IT guy" at a small company, handling software and systems as a one-man operation. That can be done in the MS space, as less expertise is necessary in general on the systems side to manage the entire stack. Even less so with Azure.

Will I be pushed out? I'm sure. I'm expecting less of a shelf life than the old hats because so many more people are raising their children to be ready for this field. Also, outsourcing/visa migration was fully implemented to diminish the industry for workers, since about 2000. The industry that was supposed to be the next buoy of the American middle class has been successfully undermined by American hypercapitalism. Greatly reducing prospects and the future for even my generation, the golden generation of children that grew up on a Commodore. A special time of astute technologists raised when we had personal computers at home, but before iOS collapsed the barrier of entry and nullified the mystery & effort required to get to entertainment.

OA> Herein is the source of the problem. The more irrelevant experience a candidate has, the more lopsided the utility/value equation becomes…

No, the source of the problem is the idea that 10 years of “C++ experience” is “irrelevant” to a project using Rails, as if development experience is somehow locked to the language you happened to do the development in.

Being a valuable senior developer is about 10% what technology you know and about 90% how good you are at working in a team to solve a business problem with a machine, and those fundamental skills haven’t changed much since 1960.

As you point out, the more experience you have, the more you realize that all these “different” technologies are mostly the same wine in different bottles. Or, as I like to say, “it’s all just software”.

The gleeful exuberance over 'new' things is something you can use against a younger programmer.

The older one who knows the vintages doesn't get as excited, because it's really not that exciting. You haven't discovered Shangri La. We've kinda already done 90% of this before, just maybe not all at the same time.

But there's good exciting and bad exciting, and it takes a while to learn the difference (I work with a bunch of people who apparently have not).

What's bad excitement look like? War rooms, for one. But they are the same dopamine hit as Stockholm Syndrome and so the battlescarred have bonded while the rest of us are doing everything we can to stay out of war rooms (I haven't been in one in well over a year).

I've started calling these people BASE jumpers, because they're adrenaline junkies. There are not so many older BASE jumpers (I hope it's not because they're all dead). I think you learn to value other things besides adrenaline. Like teamwork.

Tech history looked at from 40yr perspective, really seems like reinventing wheels over and over. I'm not sure if there is another industry with so much churn yet with a lot of rehashing of old ideas.

Alan Kay AMA: https://news.ycombinator.com/item?id=11941199

To succeed in programming, you have to work well in a business. You can't be Linus Torvalds, walking around with a big ego, unless you're so important it's hard to get rid of you.

You have to work with people well, and some of the older people I've worked with seem to understand this less.

Again, not an insult to older devs. Plenty of them are wonderful. And I could be completely wrong. Just an observation.

everyone I talk to doesn't want* a programmer in the older sense. they want people to integrate external large packages. they don't want to to test, they want to prop something up and see if it makes money. they don't want to talk about architecture and features and make plans - they just want to respond on a dime to what the market is saying.

without any value judgement - I personally don't have a lot to offer in that environment. and to varying degrees I think the hiring managers understand that (sadly, quite a number don't)

There are many places though that understand writing good code, even if it's boring, is important, and any decent programmer can go fish until they find a workplace like that.

Having a solid older developer around is important even if most of the work is boring. You're there to help the younger folk from making costly mistakes.

I recently started working on a project in which the company had outsourced it to a wordpress shop, despite it not being a wordpress site.

fast forward a few years and no one fully trusts the software so everything it does gets checked/verified by a human, and they're actually hiring people because the workload is too much.

So they brought it in-house, which is where I come in.

And let me tell you, this codebase is horrific. To give you an idea, they needed a progress bar and ended up writing a FSM with the transition between nodes being http redirects. Now, the developers who worked on this wouldn't know what a FSM is if it bit them in the ass, but that's what they built. And the data for detecting if the background processing was still running was duplicated in 3 or 4 places, which means you would get states in this FSM that disagreed with each other about whether or not processing was finished. These pages would literally "argue" with each other over it by redirecting back and forth until the browser threw a too many redirects error.

I came across some code yesterday in which the developers had created a string of multiple insert statements. They then split on the string "INSERT INTO". Said split removes the INSERT INTO from the string. They then looped over the resulting array, prepended "INSERT INTO" back onto the sql and called the DB 1 at a time. I don't think these guys realized you could separate MySQL statements by semicolon.

My point is that the codebase is horrific, written by someone who was used to the style of development you're referring to, and they made an absolute mess.

BUT

To your point. The company realizes how bad the software is and I get a surprising amount of respect when talking about what needs to happen. The result is that we're making great strides towards making improvements, and despite how horrific the code is I find myself enjoying the work because it allows me to have an aspect of my skill set respected that can sometimes get ignored by people because it's not forward facing. Good software dev is boring as shit, so when you're doing it well no one notices.

Also, this post got me to thinking. I should submit that SQL code snippet to the daily wtf.

    $codes = $db->exec(‘SELECT code from promocode’);
    if (!in_array($myCode, $codes)){
        // use it
    }

I keep running into the inverse of that at companies. People who put on a smile and a nice demeanor, but then fail to do any actual work and subsequently lie and politic to cover that up, leaving the rest of the group to play cleanup and cover. I've always loved working with the Torvalds, you do your work and all is well.

http://www.mooreds.com/wordpress/archives/871

There's various ways of describing these levels, but I think programmer/developer is less clear, and seems to suggest programmer almost as a pejorative.

That’s true. But if you haven’t learned that in 10-15 years - there is something wrong. That means the difference between someone with 15 years and 30 years would be marginal.

The most popular nowadays don't though... mobile & web have a short half life.

As someone who actually has worked as a programmer on the far side of 40, let me assure you that yes, older programmers have value. Your perceptions are not wrong. But that said, the article is right. The people who do the hiring and firing do not care about what you care about.

As the article noted clearly, the marginal benefit of an older engineer has to exceed the marginal costs. And if we’re being honest, the fact that a graybeard can use tcpdump without reading the docs carries little marginal benefit. Guess what, kid? You’ll figure it out, and you’ll do it quickly enough that the total cost of your learning won’t really compare to the cost of hiring me.

That’s why you see lots of anecdotes about the value of older engineers, but lots of articles from older engineers who know that the discrimination is real. And this is coming from someone who has managed to “stay relevant” a lot longer than most software devs.

You’re (self-admittedly) missing some of the life and business experience that comes with being an older programmer, and then expressing skepticism about direct advice communicated by older programmers. This is also so common as to be a meme:

Person A: “I experienced $something_rare at work”

Person B: “I have never experienced such things. I am skeptical of your claims.”

So sure, you can call it whatever you like - skepticsm, disagreement or debate - but when people tell you about their experiences, and then you reject those experiences because you don’t have “evidence”...well, eventually you’re just confirming your own biases.

Again, it’s not that you’re wrong - I actually agree with your perceptions of older devs. I just think you’re missing critical life experiences that connect your observations with the arguments being made in the article.

> It’s practically a trope that every time this subject comes up, the top-rated comment is a skeptical response...from a junior developer.

I looked at the top rated comment for the other times this exact same article was posted on hacker news. For none of those, the top rated comment "is a skeptical response...from a junior developer". Actually, it's more often (https://news.ycombinator.com/item?id=16934500, https://news.ycombinator.com/item?id=9361580) from a self declared senior developer. And none of those top comments really collaborate the article. Talk about confirming one's biases...

But taking into account all the anecdote from senior devs available just on hackernews, there's no consensus emerging whether the article makes sense or not.

So, at this point, I don't really feel the need for a plan B, even if being 40 years old is not really this far away for me. And it seems from the shared stories that whether this is needed or not is really based on personal experience, and is not a generally needed advice. I certainly hope to be in a path where I'm honing my skills well enough to be able to continue beind paid to engineer software after I'm 40.

In any case, I’ve said what I have to say on the subject. I can’t make you listen to my direct experience, but I’m not going to spend time arguing with you about it.

I strongly believe an employer is very short sighted if they are more concerned in a specific framework than knowledge as a whole. I agree, learning a framework doesn't take much time. They all borrow their patterns & ideas.

If your needs are urgent for a person to hit the ground running on a specific framework you should probably hire a contractor. If you want an employee you should care more about people & project skills, plus overall programming/IT knowledge.

I needed to change a string in a compiled binary and as I pulled the project down to change and compile from sources, he suggested we just patch the binary and we did in 1 minute with hexedit.

I really don’t buy that skills don’t transfer. Where this is actually the case must be people getting too locked into abstractions and never really understanding the essence

Java may not be my favorite language, but I respect how the language has both progressed and maintained its heritage. It allows the developer to build upon their skills rather than relearning nearly identical skills every time a new technology comes out.

The problem is that this 70 year old industry still behaves in very immature ways. While this may be acceptable when it comes down to attitudes towards technology, the unfortunate side-effect seems to be the adoption of similar attitudes towards people.

Every time someone says something like, "young people are more in tune with the current state of technology," or, "old people are more capable because they have more experience," they are legitimizing prejudice. That's true even when the statement is being made in an attempt to combat prejudice since it is applying generalizations to individuals.

Granted, it is very difficult to shed generalizations. Just look at my comment about the immaturity of the industry. That isn't universally true. Some companies are going to have a younger workforce, some older, some heterogeneous. Some companies are going to have old people working with old technologies, some are going to have young people working with young technologies, but some are going to have the young with old technologies and vice versa. Yet the generalization comes about because of how we frame the industry, which is one where the new replaces the old.

Which brings me back to why I respect Java: it looks both towards the future and back at the past. It is language of growth, rather than a language of revolution. Perhaps this inanimate technology has something to teach us about how we regard people: we should be encouraging growth and advancement rather than treating people as disposable.

> You’ve got a cash cow, milk that sucker!

> I know you love programming because you like technology, so this may go against your very nature, but no one says you’ve got to jump every time some snot-nosed kid invents a new way to run byte-code. You have invested a lot of time and energy mastering the technology you use, and your experience differentiates you. Money follows scarcity, and snow-birding on an older technology, if you can stomach it, may just be the way to protect your earning potential. The industry turns on a dime, but is slow to retire proven technology. It is highly likely that you will still be able to earn some decent coin in the technology you know and love even after a few decades.

> I know you love programming because you like technology, so this may go against your very nature, but no one says you’ve got to jump every time some snot-nosed kid invents a new way to run byte-code. You have invested a lot of time and energy mastering the technology you use, and your experience differentiates you. Money follows scarcity, and snow-birding on an older technology, if you can stomach it, may just be the way to protect your earning potential. The industry turns on a dime, but is slow to retire proven technology. It is highly likely that you will still be able to earn some decent coin in the technology you know and love even after a few decades.

I definitely don’t believe in the “10x Engineer” (individual contributor) - yes they do exist but are so rare they aren’t worth talking about. I do believe in being a force multiplier as a team lead/mentor.

The big picture however is still valid. Concepts and paradigms hold for decades. We still use TCP/IP. Computers still use the Von Neumann Architecture.

Looking at the details however, AWS is just a fancy GUI over time sharing on a mainframe. C# is just new syntax for concepts that are older than I am. While mobile brings new challenges, you now don't have to deal with the challenge of customers connected through a 330 baud modem.

In 1995, when I wrote my first paid for application in college, Internet was a thing for most colleges where I did some work on a HyperCard based Gopher server (long story), that wouldn’t have been possible in 10 years earlier.

In 2006, I was writing field service software for ruggedized Windows Mobile devices, architecting for semi connected smart devices is a completely different mindset than terminal programming or desktop programming. That wasn’t feasible before hardware became cheap and at least 2G was ubiquitous.

Even then what we could do, pales in comparison to the type of field service implementation I did in 2016 when mobile computing was much more capable, much cheaper and you could get a cheap Android devices and 3G/4G was common place.

But people thinking cloud computing is just “sharing mainframes” and don’t rearchirect either their systems or their processes is how we end up with “lift and shifters” and organizations spending way too much money on infrastructure and staff.

Also anyone who equates managing AWS to a “GUI” kind of makes my point, if you’re managing your AWS infrastructure from a GUI - you’re doing it wrong. 10-15 years ago you didn’t set up your entire data center by running a CloudFormation template or any other type of infrastructure as code.

You may be an expert in multiple languages but as the article said, if the company is looking for Ruby developers to write a CRUD app, they no more care that I spent years doing C than they do the years I spent doing 65C02 assembly in the 80s.

No matter how many subdomains you are an expert in, if the company doesn’t need that experience, it doesn’t matter.

I guess if it’s a seed round company with a 22yo founder they might have some bias. But the rest of the world absolutely needs devs of any age.

The first instinct would be to put 'resources' that costs little into a project, and that usually means people with less experience that requires less pay and are easier to drag around. Imagine the difficulty they will be having trying to grok your line of reasoning for respecting and going after these older devs.

The entire stack literally (for the actual meaning of literally) change completely every year. Frameworks, language, package manager, libraries, etc.

100% of my team had basically zero C++ experience before joining. Our application is developed entirely in C++. I didn't care one bit because learning the programming idioms is so trivial compared to the actually hard stuff.

Well, the listener/observer pattern is used to explain observables in order to make them familiar, but no, it's not the same thing.

Observables are streams and you work with them the via composition of streams. When viewed from that high level, the underlying protocol (the observer) becomes irrelevant and in fact, if you're often finding yourself working with that protocol, you're doing it wrong.

People familiar with functional programming will be very familiar with this style, because composition is very natural to an FP developer and the composition of all kinds of streams is in the repertoire of FP developers.

But I've seen plenty of colleagues, who are otherwise very capable people, really struggle with the concepts involved. The mentality shift from the imperative programming that people have been taught, to describing actions via function composition and then doing evaluation "at the end of the world" is a mind fuck.

Interestingly, functional programming has been with us for some time, being older than Java.

However people are not interested in actual functional programming and more recently there's this trend to classify junk as FP, just because you've got a shitty API that takes functions (often doing side effects) as arguments to other functions, but that's not FP.

So going back to Observables, as a piece of advice, don't mention that in an interview ;-)

On the other, while it's wrapped differently, the whole idea of "this object will start emitting events, and we will be having functions as callback on them defined in various objects" really feels a lot like good old java observables/listeners, even if it's applied with a different paradigm. The stream part really feels like an implementation detail to me, it's just less boilerplate than before.

Then again, it was just an anecdote based on reading code in a language I don't use ^^ javascript and typescript aren't even mentioned on my resume, for good reasons, so I should be safe in interviews !

If you work at a small-ish dev organization - especially in-house dev in a non-tech company - you can rise pretty far and become pretty senior, and your indispensability can net you a decent income. But on the open job market those skills don’t transfer as well. The senior roles in small dev shops are filled by promoting from within (because they value in house knowledge), and the senior roles in BIG dev shops are filled by hiring people who know how to operate in a big company, and you don’t have those skills.

Best way to avoid the trap is, try to work somewhere big for a bit before you get to 40, to keep that door open and make it possible to be hired into a senior role.

I'm not convinced of that. I was recently hired as a senior engineer at a large tech company that has more engineers than the sum total number of employees at every other company I worked at previously. My skills transferred just fine.

So if you don't have they right modern tech stack on your resume then you have no chance of getting hired even if you are perfectly capable of doing the work.

This is where "resume driven development" comes from. Smart and rational developers will choose tech stacks that look good on their resume, not necessarily what is best for the work at hand, because they want to make sure that they stay hireable in the future. It no good to do the best work you can do today, if you cannot get hired in the future. This is partly how new tech stacks are always so hyped even if they are always just more or less rehashes of what already exists.

I'm in my 30s and spent a couple years at a no-name shop out of college. I was getting 0 recruiters calling me. Once I realized it was a dead end I switched over to working at a Unicorn for a few years and have since switched again to big tech. Now recruiters are interested in me for senior dev roles.

https://daedtech.com/how-developers-stop-learning-rise-of-th...

And the Dead Sea Affect:

http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-d...

I'm 60+. I've been coding my whole career and I'm still coding. Never hit a plateau in pay, but nonetheless, I've found the best way to ratchet up is to change jobs which has been sad, but true - I've left some pretty decent jobs because somebody else was willing to pay more. This has been true in every decade of my career. There's been a constant push towards management that I've always resisted. People I've known who have gone into management generally didn't really want to be programming - it was just the means to kick start their careers. The same is true for any STEM field that isn't academic. If you want to go into management, do it, but if you don't and you're being pushed into it, talk to your boss. Any decent boss wants to keep good developers and will be happy to accomodate your desire to keep coding - they probably think they're doing you a favor by pushing you toward management.

I don't recommend becoming a specialist in any programming paradigm because you don't know what is coming next. Be a generalist, but keep learning everything you can. So far I've coded professionally in COBOL, Basic, Fortran, C, Ada, C++, APL, Java, Python, PERL, C#, Clojure and various assembly languages each one of which would have been tempting to become a specialist in. Somebody else pointed out that relearning the same thing over and over in new contexts gets old and that can be true, but I don't see how it can be avoided as long as there doesn't exist the "one true language". That said, I've got a neighbor about my age who still makes a great living as a COBOL programmer on legacy systems.

Now for the important part if you want to keep programming and you aren't an academic. If you want to make a living being a programmer, you can count on a decent living, but if you want to do well and have reasonable job security you've got to learn about and become an expert in something else - ideally something you're actually coding. Maybe it's banking, or process control, or contact management - it doesn't matter as long as it's something. As a developer, you are coding stuff that's important to somebody or they wouldn't be paying you to do it. Learn what you're coding beyond the level that you need just to get your work done. You almost for certain have access to resources since you need them to do your job, and if you don't figure out how to get them. Never stop learning.

Person A has become one of the world's ten foremost experts on the GPS system and other industry-critical location/positioning technologies. She is also a good, above-average programmer but nothing special.

Person B is an academic, a master of C++ who can recite chapter and verse from the language standards and writes bug-free code. He can point out undefined behavior, implementation-defined behavior, and memory leaks with ease in code reviews. He builds entire systems using template metaprogramming and is already an expert on C++28.

Person C is a highly productive generalist. His career jumped from a bank to an enterprise company to an operating system vendor to an online store. Always working on API-to-API middleware, expertly pushing Protobufs and JSON around and designing vast systems, but never gaining any expertise in an actual application topic.

Person A is going to be much more marketable later on in life, assuming she placed her bet on the right industry vertical. Person B and C may have good, successful early careers, but are often at risk of being replaced by Yet-Another-Protobuf-Slinger fresh out of college. Be as good a programmer as you can, but also build up knowledge of the business or detailed knowledge of a specific technology application that you know is not going away.

Of the three points of the article, the last two (10 years major shift, ; shift creates leveling playing field) I disagree with.

I have seen some things that felt like major shifts, but once under the hood, they tend to be re-shaping and combining existing technologies. This often put me ahead of new-comers. I had not only the current technology, but I also understood the underlying historical technology.

There is no such thing as "irrelevant experience" in my opinion. For example - it is unlikely that Algol, SNOBOL or Fortan will make a new revival. But, all that experience gave me the edge to be able to recognize short-comings or advantages of newer programming languages.

So thanks for all the nice words here. It's time for me to swap my tapes in my PDP.

Conversely the skill-ceiling on managing technical projects is incredibly high. So although one certainly can efficiently stay on as an engineer, there is a much larger pool of opportunities in technical management, and they are much easier to find if you're grinding away at a FANG / enterprise company / growing startup / whatever.

If you want to do work that rewards many years of experience, it's there. Management work is just much more likely to fall into your lap (which, let's face it, is how the median employee finds anything).

For additional context, I also don't really think "programmer" is a profession in a vacuum. You need to level up inside a business vertical to really start adding specialized value, otherwise yes, you're a fungible cog. There's no shame in that, it just is what it is.

You’re specifically talking about web development and have listed 0 of the things I, am embedded developer, do in an average day. All programming !== web development. There are more difficult problems out there than throwing up a web page. Especially in performance-sensitive applications.

I am specifically talking about the kind of development that employs, at a cursory glance, more than 65% of the development workforce. The lion's share of the remainder works on executables (commercial software) that run on a consumer device (most of which, again, is incredibly similar to web-client development in 2019), and within those specialized domains, I suggest the power-law largely still holds.

If you have some numbers to suggest that embedded engineering is a particularly good field for engineers who want a profession that rewards a high degree of specialization, I'm all ears.

Also: having worked on performance-sensitive backends for most of my career, most applications are performance-sensitive only in the shallowest sense and the marginal returns for improving performance do not in general justify the cost. One can (again, like I said) seek out domains where understanding how to build very low-latency or very energy efficient or highly concurrent (or whatever measure of performance you care about - very durable? very reliable? etc.) applications matters. But that's not 80% of the work out there.

Edit: also I find embedded engineering to be a very strange choice of counter-point. My last job alongside embedded engineers (at TE Connectivity) saw two of them defect to become fungible Java backend engineers so they could find stable work and transition into management. The remainder worked on specialized switches. Their day-to-day was managing a piece of software that polled chip readers and a REST service that hosted that information. I don't recall ever overhearing a conversation about optimizing TCAM usage or packet switching latency under load or whatever, maybe some of them got to get into the weeds on that every once in awhile. I suspect, again, that this is largely akin to having kernel development skills on a team that largely operates in user-space -- not part of the 80% -- but I am absolutely not an expert in the field).

The whole point of the post was that knowledge-intensive domains exist (and are quite common, 20% is a large fraction), and that some domains reward vast amounts of knowledge (hence power-law distributed, not normally/exponentially/etc. distributed), but that you had to seek them out.

You don't always have to go into management to follow this path though. At companies I've worked at, as you become more senior as an IC, your role expands from contributing locally on your team to contributing to the entire org. There is also often a split between the technical leadership and the people leadership on teams, which allows lead engineers and managers respectively to focus on each area.

IMO an underrated and difficult aspect of modern tech is figuring out technical practices that scale with team size, so that you can add more people without sacrificing quality, focus, speed, etc. I'd say microservices and continuous deployment are two examples of technical practices that address this, but there are more.

Amazon makes a ton of money, and (quite transparently I might add) they plow a lot of their earnings from some of their businesses into investing into their other businesses, which is what most investors want.

This is completely different from Uber and Lyft, where it's not clear that their profit potential supports their current valuations.

Edit:

I just realized what else that stood for...

It can more than level the playing field, especially when the hiring managers are particularly narrow-minded. I'm seeing more and more "degree in data science" (an academic discipline that didn't exist 10 years ago) as a requirement for what are effectively programming jobs. Of course, we can agree that this is stupid, and that not getting a job at such a company is "dodging a bullet", but unemployed is a pretty nasty bullet in and of itself.

It's a combination of many things, from brain "degradation", ageism, simple economic math ( fresh meat is cheaper and more malleable ), other more important interests like having a real life and when you really mute all the marketing BS, your delusions and wishful thinking, the actual work of being a developer/programmer in a professional setting is a really shitty job and sad life for the majority of people on those jobs.

I'm a few years from 40 and not having experience or interest in large organizations, I don't know what to do.

Programming is cool, but I always found it to be a tool to get somewhere, and that somewhere hasn't happened and I don't even know what it is or looks like.

But either way, always have a plan B and don't forget about it.

The thing is, it doesn't have to be and, until relatively recently, honestly wasn't. It's a shitty job and a sad life because we have open offices, ticket-tracking systems and daily standups. There was a time when programming was exciting and rewarding.

Where I'm at, the floor is divided in such a way that teams sitting together can sometimes have their own little "bull pen" area that's a little bit separated from other teams (if only by a whiteboard wall). This helps, and I like working in an area with just my team, but I would prefer real walls.

All a standup to me is an interruption 30-45 minutes into the day which causes me to lose an hour or more of time every single day. I basically just fart around with things that don't need much focus until the standup happens.

The worst part is that I suggested instead of standups we just send what we we would have said in the standup via slack. That lasted 3 days. The reason no one liked it? "I don't read what other people put into slack". Yeah, ex-fucking-actly. It's literally not helpful because you don't actually need to know what someone is working on that day, and if you do it's because you're also working on it and you can communicate that privately.

[EDIT] I also misread length of standup. And agreed, it's tough to have an interruption 30-45 mins is as you lose that time. Wonder if you'd be better with middle or day standups or something so at least it was between worthwhile chunks of time?

All you need is: What you did yesterday, what you are doing today, and what you are stuck on/need someone else's time with.

Some clarifying questions/interruptions from others in the stand-up are fine ("yesterday I got stuck on foo and I-" "Was it foo-bar, or foo-quux?" "Quux" "Oh did you try the flibble button?" "Why would I need to do that?" "Well since last month's release if you dont use the flibble button..." etc), but if they go on for more than 30 seconds they need to be shut down and done outside of the standup.

My team has up to 20-25 people in a standup and we're usualy done well inside of 15 minutes.

Other tips are scheduling them before a set time (e.g. before the canteen opens so if you over-run you are late to lunch), or doing them early in the day so they don't interrupt the daily grind too much -> get in at 8:30, get your coffee, 20 minutes email triage -> 10 min standup, and its 9am and you've got the whole rest of the day to do

I hated standups as well until I worked with right people.

On a more serious note, read email, get a drink, and plan your day. You’ll be talking about the plan in less than an hour, anyway.

I tried something like your "I feel comfortable maintaining this" approach recently when I was the reviewer. We have an internal geodata visualization tool that I've done some work on lately, and a talented C++ developer added a cool and useful new feature to the JavaScript front end.

He asked me to review it and said, "I'm sure you will find a lot of things I should change! This is my first real JavaScript project other than some hobby stuff."

And he was right. There was a lot of stuff I would have done differently. There was a mix of jQuery and document.getElementById, a fair amount of repeated code, var instead of const or let, and so on.

Our "house style" for reviews would have been for me to comment on every single one of these things line by line and expect him to change them all to my satisfaction. It would then require a second review pass to clear up misunderstandings, and a third to see if it all ended up OK.

Instead I told him:

"Your new feature is awesome! You're right, there are a lot of nitpicky things I would change in the code to bring it up to more modern JS style, and I'm glad you asked about that. But I didn't find anything that looks broken or dangerous. And the feature works, right? I could spend half a day writing comments explaining everything I would do differently, and that would keep you busy for another half day fixing it up. But I know you have more important things to work on right now, so maybe we can try something different. Go ahead and submit the code as is so people can start using it. When I get a little time I will just go ahead and make the changes I'm thinking of. I'll add review comments on my own changes and send it to you for review so you can see what I changed and why. That will avoid a lot of back-and-forth. I think it will save us both a lot of time and be a more pleasant experience too."

Needless to say, the developer liked this idea. And his manager was within earshot when we discussed it and thanked me for thinking of this approach.

I still haven't made that update, and this reminds me to do it sometime soon. But the code still works, people are using it productively, it has not failed once, and who really cares if there are some minor imperfections in the code style? None of our code is perfect!

In this case actually I would have taken the half an hour and sat with them to explain what I think should be done differently and why, prioritized by importance.

Reviews done through tools work if there aren't many comments and if the basic design is ok.

I've seen reviews where someone's not skilled enough and they have to be taught idioms in dozens of comments in 10-20 patch sets. It's pretty horrible, but the positive side is that at least they're not merging crap.

I resemble that remark! Yes, procrastinator here. ;-)

The thing is, his code is plenty good for now. Even if I never make that update, the code works and people are getting useful results from it. There's nothing overly complicated about it either; I or anyone else could pick it up and easily make any simplifications and improvements whenever needed.

And this developer is working on far more important things for the company, mostly in C++. I made the call that it would be better for our business to let him get back to that, since any improvements to the JavaScript code style on this internal tool simply weren't that urgent.

But I do appreciate the reminder and I will get to that update soon!

Few things to consider: - linters to help move away from code style comments - Peer code reviews (if possible) - inform your team/boss of bike shedding - use a tool like reviewable.io where comments can be marked as blocking or not. I’ll often comment on preferences and block on issues.

A code review where the boss reviews code is pathological. When experienced peers do the review it can be brilliant.

In fact I would only trust a team of very competent seniors not to need code review. Even then, getting another opinion on your code can be worth it.

Though the way I scan the code during review does change by how much I know and respect the author on a technical level.

That correlates with but is not identical to their formal seniority.

Indeed. It's almost as if it's a bad idea to take people working in a field where creativity and careful thought are fundamental and a wide variety of experience with different but related ideas is often helpful and then try to turn them into interchangeable commodities with the whole process dumbed down to the level of the least competent developer or manager in the team.

For my own career, escaping that sort of foolishness was the single biggest benefit when I made the jump to freelance work and even more so when I first became a founder. As soon as you go independent, you're no longer dealing with a subordinate employer-employee relationship, where everything you do is subject to the whimsy and caprice of whoever pays your salary. Instead, you're dealing with a business to business client-service relationship, where your objective is to provide the service the client needs. How you choose to solve whatever problem they have in terms of technology or process is much more down to your own professional judgement. If you do follow entrepreneurial route, you become effectively both client and service provider in that sense, and it's what you learn from your market research and customer relations that guides your direction in often even more general terms.

There was a time when programming was exciting and rewarding.

IMHO, it still is, as long as you find an environment where using fun things to get useful results is the emphasis. Mind-numbing corporate box-ticking is soul-destroying in any field.

We're privileged to work in a field where all we really need to do useful work is often a laptop, an Internet connection, and a willingness to use our brains, and where that work can still be valuable enough to others to make a very nice living off it, and where there is no shortage of potential customers.

Now, there's nothing wrong with being a competent professional who turns up and writes software during office hours and then goes home to enjoy life with their family/friends/hobbies like anyone else, and maybe for those people the structured corporate environment is helpful. And of course going independent has other challenges that aren't just about technical skills, and those are not for everyone. But for anyone who wants more than an office job and doesn't mind taking on a broader skill set to operate independently, I don't understand why they would continue to work in the kind of toxic employment environment we are discussing today. I suspect that in many cases it is simply ignorance (meant literally, not derogatively) of the possible alternatives and the paths to transition to them.

Incidentally, as a convenient side effect of working as an independent professional or through your own hopefully more enlightened business, the sort of ageist nonsense that motivated today's discussion also largely disappears. For a lot of clients outside the tech bubble, a 25-year-old in trendy clothes spouting the latest buzzwords is much less impressive than a 45-year-old who immediately gives off a competent, professional vibe. And if you're the 45-year-old who did keep up with developments and has had an extra 20 years of honing their skills, your rates can reflect your greater capability and productivity, which is much harder to achieve if you're still someone's employee at that point.

I am a few years away from 40 as well, but as a freelance software developer who works remotely, I can only say I /love/ my job (most of the time) and hope to do it for many more years in this capacity.

Noise-cancelling headphones are mankind's greatest weapon in the hopeless war against braindead management practices.

We are so "important" to mankind, yet the best we can do is to buy Noise-cancelling headphones.

If you think being a programmer in BigOrg, Inc. sucks, then take a summer and work on a construction site or with a landscaping crew. Trust me, you'll yearn for that loud, open-plan office soon enough. Modern society would quickly implode without plumbers, yet actually being a plumber and crawling around under houses in rat shit is not very fun.

> brain "degradation"

At 40? If you're suffering from loss of mental capabilities to the point that it affects your performance at work at 40, you have medical issues that need immediate attention.

> simple economic math ( fresh meat is cheaper and more malleable )

I've seen this stated many times, but nothing is forcing anyone to offer a particular salary or demand a particular salary.

In my 40s, much of that has changed. I'm beat mentally after a 6-7 hour day of coding. I can only keep smaller portions of the system in my head easily.

It's possible that I was blissfully aware of how shallowly I understood things or how ineffective I was in hours 7-12 of a workday in my 20s (and both of those no doubt have shreds of truth in them), but it seems way more likely that I am noticing a genuine difference in mental ability over the intervening two decades. None of that seems medically abnormal to me.

I think of all the edge cases and pitfalls that I wouldn't have in my 20s. I have an easier time reading and understanding documentation, using libraries, reading and understanding other people's code. I think I'm also much more sympathetic to the poor sod who wrote this broken code under a time crunch 5 years ago.

I remember 10 hour days in my twenties that shortly turned out to be a total waste of time.

Even if you can only work 6-7 hours a day now, you're most definitely spending that time a lot more efficiently than you did a decade ago. You don't need to keep more information in your head at the moment because you have decades of wisdom guiding your decisions.

> I've seen this stated many times, but nothing is forcing anyone to offer a particular salary or demand a particular salary.

I didn't think bosses& hiring managers trying to pay the minimum and get the maximum was a contentious point. Our industry is still made of young people who prefer younger people to do their work, for both economic ( many times short sighted ) and social reasons.

I thought that wasn't really supported by anything significant. Life, health getting in a way is not a decline of mental abilities.

What do you mean by this comment?

Younger people are willing to work for less and I don't see how your comment relates to that idea.

Be a median software developer, pair up with a spouse making the national full-time median, now you've got a $160,000 household income (which doesn't sound special in SV). Married that's $115k-$125k in take-home pay in most of the country.

$160,000 family income vs a $350,000 house. That's the kind of ratio that tilts life a lot further in your favor in many regards.

I'd love to give you a tour of what people do for work, and then you can personally decide how bad programming is as a profession.

I just don't use other people's tremendous shitty jobs to glorify mine.

While individuals certainly experience really bad situations in every walk of life, programming is an exceptionally valuable and versatile way to make a living, and offers a level of freedom and economic mobility that most people in most fields could only dream of.

Most people sit at an office in front of a computer for at least 8 hours a day, some of them are developers. Most "problems" they "solve" are very distant from the "Changing the World and give meaning to your life, one PHP line at a time".

It's a great gig, but a sad life when you'll look back on your deathbed.

Fresh, healthy, high quality, free food catered for 3 meals a day? Check.

Best healthcare possible provided at no cost? Check.

Stocked kitchen with all kinds of snacks, high end coffee, kombucha etc with ability to make requests? Check.

Freedom to come in when I want and leave when I want? Check.

Work remotely when I want? Check.

Any equipment I want at any cost? Check.

Top of market pay for size of company? Check.

Beautiful office with natural sunlight, plants everywhere, and fresh air? Check.

Autonomy and creativity in my role? Check.

Top percentile talent as coworkers who are genuinely amazing collaborators, interesting people and great to work with? Check.

Like with all professions, there are depressing jobs and great jobs. If you're a dev working at a paper mill in the midwest with draconian dinosaurs as management, yeah it might not be the best gig. But if you work at a company that values software and understands the leverage of great developers, then I can't think of a job that's more cushy and fulfilling.

I get to sit or stand when I want (I have a motorized, adjustable standing desk). I can go for a run mid-day if I want. I can hit the gym if I want. I have any number of options. If I choose to sit in front of the computer all day, that's usually MY fault (but to be fair sometimes there's a launch date looming that results in me working extra).

It's all about choice. I have that. Many professions don't.

I go to my family reunion and out of 5 of us in the same age bracket, everyone else has to rush back to their jobs in 2 or 3 days, whereas I can spend the full week with the "old folks" - that's time I can't get back.

Am I changing the world with my code? No, not really. Am I helping people in turn work less while still getting to solve increasingly harder problems? Yes. I can only think of a few other professions that would keep me as happy, and none offer the reward/effort level of this.

Maybe the one difference is I started with computers out of a love for problem solving, not for the other things I said. Those are just a nice side benefit I now won't give up now that I'm older by a bit.

University of Phoenix pitch, it is not.

Compared to what? Have you ever worked manual labor, retail, food service industry, etc?

Oh man, I cannot relate to this at all. I feel very lucky to be a software developer - there are far more boring jobs out there, that pay far less, with less flexible hours.

What is a "professional setting" in this context?

You know, being the brick mason of yet another cathedral of delusions and failure as most business are. Which is life and I don't really have a problem with that.

But we are all human and after a decade of this shit, it gets hollow and meaningless.

Without maturity, a strong social network and discipline every solo venture will end up in isolation and depression.

But I still try the usual side projects that get started and not finished like everybody else. :)

Right now, I just wish I would find something 80% business and 20% tech with a feedback loop comparable to a plumber ( work for a day or 2, when it's done its really DONE. Move to next job )

I'm happy you opened up a little as to how you feel. If you want something that's 80% business 20% tech, I can high recommend getting into "high end" consulting. "High end" just meaning rich people, their houses, and a small smattering of businesses that they themselves have a high earning to effort %.

I don't mean writing code, I mean doing networking/server work/maybe some desktop stuff. I know that doesn't sound glamorous, but you get to make good money (really good money), most jobs are DONE when you're done, and it's generally very low stress. (learn and understand VLAN's and that level of networking and you're already in demand for a lot of people)

Most of the job is learning to setup/meet expectations, know how to talk to those kinds of people, and other business end skills. You'll also never age out - these kinds of people have long ago learned to identify other markers and often are older themselves.

I did this for years and it fit all the things you say you'd like and it left me with plenty of time to write code on the side (or not, the time is there to do what you love.)

My previous job (and my first ever outside NZ) was working for a multinational electronics company in their Moscow Russia R&D lab, a job I got when I was 52.

Compare to Fortran or supercomputers. Was important, isn't much so these days, although is still used.

What I'm saying is that you got on a train that has been running longer than some other trains, hence you meet older people on the train. As someone who has little interest in management I hope to be as successful as you, in this sense of picking long distance trains.

So, is it still preferable for the manager to not hire anyone and let the work sit undone rather than to be forced to work with a detestable "older" worker?

Perhaps the government should start giving disability status to people because they are over 40.

Interesting statement. Someone recently told me the biggest problem with US Presidential Candidate Yang's Universal Basic Income plan is that people who have had a successful career in one field their whole life often do not want to learn a new career even if you help them financially while they transition. For reference, the discussion was about winning an election more than solving a problem.

It's very interesting to hear the above statement from someone in tech vs a different industry. Reminds me how similar people across all industries are when often some of us tend to feel unique for some silly reason.

It's not only being successful, but also being happy with the characteristics of software dev work.