I see a lot of lack of appreciation for older, more experienced programmers in the field. Perhaps this is why things keep getting reinvented all the time, and the pendulum keeps swinging back and forth as we don't learn from previous generation's experiences?
Too much fad and hype driven development these days.
What I find is you have people that gain 10 years of experience in 10 years and people that get 1 year of experience repeated 10 times.
The field changes, it's changed significantly since I started 10 years ago. Yet there's a fairly large contingent of devs that aren't keeping up. I've interviewed old devs that are at the top of their game and old devs that are no better than the interns we have. I've worked with the same.
There are certainly older devs who only know $thing and can be kind of myopic, but this works the other way too: there are also young devs who only know $thing and are rather myopic.
Another thing I've seen is people complaining about "old geezer not keeping up" is used to shut down conversation about whether $new_fad is really the best choice, and $old_thing may actually be better. Not saying that was your intent, but I've seen it used like this many times.
Not all that many years ago someone saying "no thanks, I'll stick with SQL instead of no-SQL" and even "no thanks, I'll stick with Java because I think the static typing is better" could be seen as "not keeping up".
> There are certainly older devs who only know $thing and can be kind of myopic, but this works the other way too: there are also young devs who only know $thing and are rather myopic.
This is why I tried not to classify this as a young v old thing. I don't think it's the case that old devs can't keep up. I think it's the case that some devs don't keep up regardless of age.
For young devs, it's hard to know if that's the case or if it's simply inexperience. For old devs, it's far more glaring when all their experience is with VB6. I think that's where a lot of the ageism in software hiring practices comes from.
> Not all that many years ago someone saying "no thanks, I'll stick with SQL instead of no-SQL" and even "no thanks, I'll stick with Java because I think the static typing is better" could be seen as "not keeping up".
Perhaps some saw it that way. I never did. I would say that if you were completely unfamiliar with no-SQL, you likely weren't keeping up. Just like if you aren't aware of k8s or docker today, you aren't keeping up. Whether or not you chose to use those techs is entirely different from simply outright rejecting them without evaluation.
It becomes even worse if you run into people who operate on cutting edge knowledge from decades ago and insist on it.
I've seen people organize their data in a cache-pessimal way in order to squeeze out a couple of CPU cycles, for example. It becomes really tiring when you constantly have to whip up a benchmark just to settle debates on things that have been common knowledge for basically forever now.
Or sometimes it's the opposite and you get shoved "Premature optimization..." quote up your change request during every code review and fighting person's bad habits requires you writing benchmark or referencing 5 articles with examples for every little thing. It's maddening.
I've heart this being repeated a lot so it is likely not something you came up with yourself.
I always become suspicious when a software engineer has been working on a problem +10 years. The type that spend their time upgrading angularJS to angular or something like that.
You found this, really? You're not just repeating a very common and widespread phrase that's been found by other people and in use for decades? ([1] [2])
This is a weird way of twisting their words. They didn't "find" the phrase themselves, as in coming up with the words, rather they found that in their experience, some programmers behave according to said phrase. You are parsing the word "find" in the incorrect way in this situation.
Phone development is a continuous slog through ever-changing APIs. An older programmer hardly helps here. In fact, this is probably one of the few places where I might agree that younger programmers are better--it takes an enormous amount of energy to keep up with phone programming changes and that's something that youngsters have aplenty.
Web programming is a similar treadmill except for the fact that you can opt-out. If the client demands some fad technology, well, then experience doesn't matter. If the client simply wants a solution, then experience can be a godsend. I've watched a couple experienced programmers deliver amazing web solutions really fast--they used well-trod, boring technology that they knew very well.
Embedded programming simply demands greybeards. I haven't seen an embedded project yet that succeeded if it didn't have a majority of people with 15+ years of experience and couple above 25+ years. So much will go wrong that it's more important to design around the failure modes up front--and you have to have been around the block a couple of time to understand what those are in order to avoid them.
> Perhaps this is why things keep getting reinvented all the time
This is a good thing, in my opinion. Not only does reinventing something give a new generation an opportunity to learn how to design, but it also gives that new generation context and knowledge about the product when it is complete.
> we don't learn from previous generation's experience
This is a serious cultural failure (and it happens globally). Very few of us sincerely engage with the past, in my opinion, because it takes a lot of effort to do so. And either it's not worth the effort on an individual level, or we haven't been allocated the time/resources by management that it would take to sincerely engage with the past.
One thing I have been curious about is: where are all the old programmers? I want to learn from them but very few put out material, and so you gotta get lucky that you work with one.
Most of the material out there on YouTube, books, and blogs seems mostly dominated by younger people (30s and below). I'd love to see people who really know what they're doing put out some material.
Losing the enthusiasm to blog and create videos. Also I guess a certain lack of not giving a damn if you actually produce something valuable. For example 10-15 years ago I was very eager to write down every little thing I learned, but after a certain time you either notice that you don't know a lot, in the grand scheme of things, and your bar for "will I publish this" can go up a lot, or you're suddenly working on highly specialized or super secret (offficialy) tech where you can't really publish anything... or you actually notice that you become proficient in stuff you find generally uninteresting. Best example is.. enjoying your work but not feeling in the mood to spend your free time on explaining some weird quirks to the general public.
Also writing books is something you need to enjoy or at least feel driven to do. For most people it's not worth it in a monetary sense either.
What's wrong with fad and hype driven development? It may be better to replace software regularly than to find yourself or your organization dependent on something ossified in place.
In the long run it might be better to treat software as "fast fashion" rather than something meant to last forever.
What's wrong with fad and hype driven development?
Ostensibly nothing, so long as you can tell when things are better. If you're trying new things and taking on new, better ideas quickly then you'll improve rapidly. If you're also "failing fast" and throwing out new things when they don't work then you'll improve even more rapidly.
If you're abandoning good tech simply because it's old, and not fully understanding the drawbacks of the new things you're switching too, then you're building an empire of tech debt that all your good team members will eventually get sick of fire fighting and they'll leave.
Novelty doesn't make people loyal. Working on strong tech that people are proud of does. Sometimes that requires a deep dive into some tech over a number of years.
> What's wrong with fad and hype driven development?
The "flavor of the month" band wasn't as good as The Rolling Stones. That's not the end of the world if all you did was buy their CD, and then never listen to it again after the month was up. If you completely rebuilt your stereo to try to make that CD sound better, though, that gets more expensive. (Especially if you rebuild it again next month for a different band.)
Development is more like rebuilding the stereo than buying the CD. It's expensive. It takes time and money that could be spent on other things.
Worse, in replacing dependencies, you may replace a dependency on something that works with a dependency that doesn't work nearly as well. You may replace your Corvette with a Corvair. (And spend time and money to do it.)
If you have battle-proven tech, there is a place for eventually replacing it. Eventually, though. Not very quickly. And when you do replace it, don't replace it with the fad of the month (or even the fad of the year).
> Pete concentrated on building a system [in COBOL] that works for him and his clients.
If that system isn't replaced before Pete retires, it turns into a significant hidden risk.
You don't know how dependent on something you are until you try to replace it with something else. If hype is driving the replacement, so be it. An organization can make replacement a regular practice and get good at it; or it can find out when it unexpectedly becomes necessary.
I'm a seasoned citizen who sometimes complains about ageism on HN, but not today. I've come to realize that some of the complaints are valid and think it may have to do with "resting on your laurels."
To 'rest on your laurels' means that you get lazy or complacent about what you could achieve because you're too busy basking in the memories of former glories. [1]
I've noticed in my older programmer friends and myself. Because you were a lead developer on a famous program in the 80's or 90's doesn't mean you know anything about programming in today's multicore, distributed processing world. If you're not a life long learner, you probably don't. But you have a big ego, which most people think is justifiable, and it gets in the way. It's happens to the best of us.
I fight this tendency in myself by practicing the Zen concept of the beginner's mind [2] and egoless programming [3]
This works outside of programming too. For example, I've always hated Los Angeles since the days when it was hot and smoggy, but last trip there I told myself I would look at it with fresh eyes. I discovered a lot of cool things about the place that I didn't see before.
Here's what I'm excited about: When young I had a burning passion for programming but 30 years of programming for corporations and other "profit centers" slowly burned me out and used up my passion, leaving none for my self.
Now that I'm retired I'm doing the best programming of my life. I got my passion back. I'm seriously thinking of devoting a few years to seeing what I can do when I have the freedom to take my time and do it the way I like to do it. I'm always inspired by the story of Colonel Sanders who was 62 living on a small social security income when he started Kentucky Fried Chicken. Who knows, retirement may be the greatest adventure of my life if I make it that way.
Do you have a blog we can follow your adventures on? I just had a baby, so the only things I'm doing are sleeping, working, and feeding/diapers right now. It'd be nice to read about how you're spending your increased free time :)
No, I'm too busy programming. If my experiment is successful maybe I'll write a book for programmers: "How to rediscover your passion for programming in your senior years" Congrats on the new baby. Mine are approaching middle age, which is a whole other trip. It's weird to notice your kids are starting to have mid-life crises
I think ageism is overstated. What happened is way more young people entered the field since the industry has grown so rapidly over the past few decades. So it looks like there are no old programmers or like they are getting pushed out but it's mostly just there are a lot more young ones.
Pondering the societal conditions throughout history that have preceded various cultural flourishings it seems one common factor is that something fosters a broader diversity of interaction between individuals of different backgrounds.
Sometimes it's a disruptive technology. Sometimes it's a terrain advantage. Sometimes it's the Medici family holding endless dinner parties and being patrons of the arts. Sometimes it's a quiet pub on a loud street. Sometimes it's a melting-pot society that funds public education. Sometimes Alexander the Great forcefully unites people along a stretch of coastline. Sometimes it's a small room of thoughtful people committed to changing the world.
The part missing from all conversations about 'young' vs. 'old' programmers is: what about 'old' people who enter the field late, and aren't multiple-decade veterans of it?
That is where rampant ageism really happens. We don't just need old, highly experienced programmers; we need programmers of all ages.
The unfortunate reality is one really good programmer can oversee 5 or 6 2-4 years of experience programmers. Almost all corporate software, even in FAANG, runs this way. People want to believe their 20 years of experience counts, but it doesnt. Mostly your ability is capped by your intelligence and exposure to other really good programmers. But it plateaus very fast, and there is no learning after a certain amount of years of coding (I would argue at 4-5 years of good/varied experience mark).
Whats more, I would argue that the idea that the human brain can hold ten years of programming information to be absolutely absurd. The universe of what you can learn technically and recall is smaller than that time frame. World class physicists, mathematicians, chess masters, etc peak young. The brain doesnt need a decade to reach the heights its capable of.
> there is no learning after a certain amount of years of coding (I would argue at 4-5 years of good/varied experience mark).
If you stopped learning after 4-5 years in the field, the barrier you hit wasn’t the lack of new things to learn. It was your own ability to learn them.
> I would argue that the idea that the human brain can hold ten years of programming information to be absolutely absurd.
You’re demonstrating the ignorant hubris of youth quite successfully.
To be generous, if we're talking coding specifically, 4-5 years is a reasonable cap in my opinion.
Coding is not the same thing as software engineering or systems/architecture design or technical leadership or... All of those things can be improved significantly through a human lifespan. The act of writing code? Not so much.
The other caveat is that most people will not be getting enough experience to hit that cap in 5 years. You need the right environment, mentors, etc.
You really contradicted yourself when you said that 'one really good programmer can oversee 5 or 6 2-4 years experience programmers' - and then said that experience counts for nothing. That experience is what allows you to oversee the junior folks. That's the value. And yes, it does increase logarithmically. But also the pool of junior folks who make it to senior and then staff and then principal drops off logarithmically too as they pursue management, or farming.
Career progression as an IC involves increasing not your technical output (although technical output matters) but primarily your blast radius and influence. You can get that by leveling up in multiple areas (iOS + Android + Server) or by pursuing that logarithmic growth in one deep technical area.
So yeah, you can only get so good at iOS development - but if you want to keep learning, pick up other complementary skills and leverage them. This is a choose your own adventure game and yes, you can fail.
I'm not particularly old, but I do mentor many staff engineers in the course of my work. Some a lot older than me, some younger, some the same age (although not too many younger).
I am saying the 20 years of experience is mostly not needed. 90% of programming roles can be done by 2-4 years of experience candidates. With a bunch more in that percentage done by young talented people. The old candidates are discarded for good reason, they arent better than their younger competitors, even if they write solid code.
>90% of programming roles can be done by 2-4 years of experience candidates. With a bunch more in that percentage done by young talented people. The old candidates are discarded for good reason, they arent better than their younger competitors, even if they write solid code.
I think I can agree on that
Majority of programming is web dev and other boring software which requires business knowledge from domain experts and programmers with some experience that just care. At worst they'll fail and refactor.
Yes, the main killer factor for programming is being able to pair your coding skills with another skill (e.g. business/domain knowledge, management, marketing, etc.). Many programmers don't do only programming as time moves on. They add other skillsets or branch out.
The thing is, I’ve seen pretty much every shape of problem you are going to come across and have a suite of different solutions I can apply. And I can pull together completely new solutions using the knowledge I’ve gained over the last 30 years.
It’s not about being able to write solid code - anyone can do that. It’s about experience.
Out of curiosity, what level did you achieve? This isn't a criticism, I think it would help color your perspective.
[edit] For instance this is the kind of thing I'd expect to hear from like an E3/E4. An E5 knows what to do to get to E6 and understands the value. An E6+ would never have achieved the level with this perspective.
L6. I've just seen the pattern of a high performing engineer running a team of ten junior engineers. No more high experienced candidates needed over that one. This is on high TPS distributed systems. I've also seen two years of experience candidates writing code as good as anyone else. Domain specific for sure, took them two years on the team to get there. I've also spoken with many prinicpal engineers and think they provided no extra value over many other engineers. Its a level to aspire to, but most are just corporate strivers, many many people under them could replace them.
> I've also seen two years of experience candidates writing code as good as anyone else.
I so so so severely doubt that. Two years of experience is barely enough to learn one of the most important experiences of all, maintaining your two year old code ;)
I've only got 7 years in at one FAANG maxed out at L7, so you've got both years and diversity on me in terms of experience.
With that said I profoundly disagree about the plateau in effectiveness as an absolute thing. I started programming professionally when I was around 20 and got a lot better quickly. By about 24 or 25 I was pretty deep into the asymptote of what I was learning at various startup jobs.
I went into a marquee shop at 28 and my ability exploded for several years, before kind of sloping off again for maybe the last 2-3 of those 7 years. I left and did more entrepreneurial stuff in completely new (to me) domains, and have seen another crazy surge in what I can accomplish that's still running right now. I currently run circles around myself from a year or two ago.
There were definitely incredibly capable up-and-comers doing amazing shit at 23 when I was playing pro ball, but the truly heavy hitters skewed (again not exlusively) 40, 50 and up. It takes time to master a craft. Even the galaxy-brained 20-somethings were intellectually brute-forcing past some deficiencies in experience.
You go through Coders at Work which I hope most would agree is a pretty good sampling of real legends (it unfortunately doesn't include many women, I think just Allen, it's a product of its time in that sense and people like Liskov are no-brainers to have been included), and these folks weren't 25 then, and many are still kicking ass today. Brad Fitzpatrick I think was the youngest one when it was released in 2009 and he's kicking more ass now than ever.
Maybe in some group explore/exploit banditing the color of a button in the GMail compose window 20 years of experience makes little difference (recent meme from /r/ProgrammerHumor), but I think that meme is a caricature.
Right but you sound very talented, just need one of you to watch the code of ten junior engineers. Youre ability to achieve L7 with only 7 years of experience proves my point almost exactly. Your yoe didnt matter that much. You didnt need fifteen years to start accumulating real knowledge. Regardless of the leaps and bounds you are making, the corporate world doesnt see it that way, and the reliance on leetcode for interviews proves this.
I don't know about "very talented": I take my job/craft seriously and as a result I'm good at it, but I've been programming in one form or another for 30 years, I got a hand-me-down original IBM PC when I was eight, and a hand-me-down 386 / copy of K&R a few years later. I still haven't decided if the ubiquity of access to a JS programming environment (good thing) outweighs high barriers to entry of figuring out how to write native code on e.g. a kid's iPhone (bad thing).
I think it remains to be seen where the corporate world lands on all of this. It's still fairly early days on 22-year-olds being able to raise VC and hire a bunch of other 22-year-olds to go "disrupt" some market. The results so far are mixed. Too soon to tell.
As for leetcode interviews: no one likes them, as I've said elsewhere I didn't like being interviewed that way and didn't like interviewing others that way (I could go a little off script to try to dial down the false negatives a bit, but there were in general pretty clear non-discretionary standards). But every high-prestige admissions system has some standardized or semi-standardized test. For undergratuate in the US that's SAT. LSAT/MCAT/GMAT you name it.
Companies don't want to be using extremely unpopular tests with lousy recall. Interviewers don't like it, interviewees hate it, and it has all kinds of structural biases against people who didn't just finish a CMU undergraduate. I personally might flunk a leetcode interview at a company I contributed absurd amounts of good code to.
But no one has thought of something better yet. It's a real opportunity.
It took me 15 years of development to start feeling like i really knew what i was doing (eventhough i have a CS university degree), and i keep understanding new things every month on my job. And that's just the coding part, i'm not even mentionning the human aspects when working in a team.
The way i analyse a problem,
approach technological solutions, design system architectures, pick a programming language, are all extremely different from how i did it 5 or 10 years ago.
For a lot of us, software development is much more similar to craftsmanship than breakthrough scientific research.
This is a function of what youre exposed to. Go work for a big software company and switch teams to a different domain every six months. After three years, you will rival almost any engineer. The issue is people get mostly worthless or extremely siloed experience, and so they take a long time to build a complete picture of how to write software in their head.
Switch teams to a different domain every six months?
In the domains I’ve worked in, it might take six months just to get the basic idea sketched out and working. The current project has a timeline of 8 years to full completion — two years just to get to the first minimal release for a subset of our problem domain and the hardware to run it on.
It sounds like you’ve been doing unchallenging work in unchallenging domains and have acquired a much too inflated opinion of yourself in the process.
I've worked on teams with 6 month ramp up times. Almost always this happens because there is an absurd amount of domain/business knowledge encoded in some massive 500k line code base. Tenured engineers gate keep with domain knowledge. The real learning happens by switching between working on those types of systems and then moving to greenfield to implement the patterns you observed.
How do you know if you did a good job if you leave after a few months? Did you leave a beautiful work of art, a bug-ridden unmaintainable mess for others to clean up, or anything in-between?
A large part of experience is doing things that seemed like good and reasonable idea at the time, and then discovering that it actually wasn't. And how do you know what are and aren't good ideas? By sticking around and seeing what does and doesn't work.
i've been doing both big corp, small start up, freelance gigs, backend, mobile app, web development, huge system migration with running customers, database design, etc.
I can guarantee you that 4/5 years xp is absolutely nothing. You can barely scratch the surface.
what you do start get after 5 years however, is the feeling that you've seen it all ( because you may have, but only very superficially). It makes people like that extremely dangerous.
> Mostly your ability is capped by your intelligence and exposure to other really good programmers. But it plateaus very fast, and there is no learning after a certain amount of years of coding (I would argue at 4-5 years of good/varied experience mark).
This is very false in the embedded space. It may be false in other spaces as well.
I’m also in the embedded space and I totally agree with you. I have 12 years of experience and I’m still getting better and learning new things. I worked with some people with >30 years of experience and they were by far the best and most knowledgeable programmers I’ve ever encountered.
Maybe it’s because embedded programming doesn’t change as often as other areas, such as web frameworks. The experience I have from 12 years ago of reading data sheets, interfacing I2C sensors to a PIC32, and debugging by turning on LEDs is still relevant today, even though I have moved on to much much more complicated projects.
I don't know the embedded space, but distributed computing, web development, ML systems, etc all are this way. This assumes you are actually getting good experience (which most people do not).
Maybe if you are writing a new database that will be sold as an offering at AWS/GCP/Azure, but those roles do not apply to 99.99% of engineers.
i strongly disagree and found it interesting in the recent 5 hour lex friedman interview with john carmack that he said even at his age he was still getting better every year.
i think programming actually belongs to a category of activity, along with pure math, where crystalized intelligence is the primary driving force.
> human brain can hold ten years of programming information to be absolutely absurd.
Wow, so this seems to completely discount the very idea of expertise? Do you believe it simply doesn't exist. Strong dunning-kruger vibes coming from you right now. Naivity I only wish I could bathe in LOL
They've apparently (other comment) hit 10 years in their career, guess they have no value to add and from here on out it's just a decline as they forget everything they ever knew. Might as well put them out to pasture...
No look at when top mathematicians arise, in their early 20s. Intellectually demanding professions (like stock trading), dont need 10 years to rise to the top. You either have it or you dont
Strange to presume all domains are equivalent. Stock-picking and math-savant-esque talent are very distinct from almost every domain where one would value tenured expertise: surgery, aeronautics, civil engineers. Goodness me: consider your blind spots.
The hightest paying companies all use leetcode. They do this because they believe performance on the job is related to IQ. Trading firms hire programmers at 400k right out of school, hiring MIT grads. Its all the same.
Painfully starting to understand that this is why the greybeards either move to management or retire. It becomes increasingly precarious to justify your salary as an IC compared to people with less experience. Am I really 2x as productive as the saavy mid-level engineer with 5yrs experience on my team that makes half as much? Probably not.
I am 50. Between 40 and 50 I hardly changed a line of code for pay. I did other things, requirements, managment, coordination and stuff. Now I once more am developing. The 10 year break for me gave me new appetite for what I used to like but grew tired of. But to be honest, I have forgot a lot and need to be humble about it. But in other ways, I have experience and I can clearly tell my younger colleagues respect my judgement and opinions.
Management at software companies know this, they just don't speak it outloud. The hiring decisions speak volumes. Top software companies will pay 300k for a 3 years of experience candidate, because the value that engineer creates is comparable to a ten years of experience candidate.
The answer there is level/competence-based, rather than years-of-experience based compensation structures. If you're only 50% more valuable than someone else, you should make ~50% more, not 100% more. Note that these figures are in total-cost-to-company terms, which might mean your own gross pay would be more than 50% higher if social and per-employee-overhead charges cap out.
Part of the issue is people with 25 years of experience think they deserve more than someone with "only" 15 years and when they don't get it, it's because of ageism or age-discrimination not accurate assessment of value.
Yep. Engineering talent increase due to exposure is a sigmoid curve that tops out after 1-2 years. There are social paper cuts that make you _wiser_, but not a more effective engineer in terms of "things shipped" and "problems fixed"
EDIT: inb4 downvotes roll in to your post because it's an uncomfortable truth
It's not that its an uncomfortable truth, of course your growth in technical ability in a new field slows down quickly but that's not where your value is derived from. It's not what your company is looking for from you. It's not how you level up. If you continue in this vane you will plateau in your career very quickly and you will wonder why.
You are describing technical contributor - but that's not really your job. The sooner you realize that and develop the skills that matter, the more quickly you'll make the mid/high 6-figure bucks. Maybe 7 with equity appreciation.
There are plenty of sub-fields where you do want someone with experience.
I wouldn't put an iOS developer into a position where they have to write kernel code.
yep. The sooner you come across it, the sooner you start building skills that actually help you become more effective for your effort, like learning how to build teams and managing the social graph of an engineering organization.
We've raised the floor so much in FANG tier companies, that the differential of programming skill isn't what makes you more effective. I mean, save for the top 1% freaks ;P
Too much fad and hype driven development these days.