We need young programmers; we need old programmers
blog.ploeh.dk
blog.ploeh.dk
Too much fad and hype driven development these days.
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.
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".
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.
They lack foundational software engineering knowledge/opinions
Use their IDEs as if they saw it for the first time
Lack of experience when it comes to architecture
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.
You can argue everything with "because of performance reasons" because it requires way more effort to actually check it.
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.
[1]: https://news.ycombinator.com/item?id=4627373
[2]: https://ask.metafilter.com/62762/What-is-the-source-of-this-...
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.
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.
Without being too reductive, software is subject to the theory of economic profit and thus tends to ~free.
Churn is the natural response. It artificially create the sort of work that forces users to spend money in the future.
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.
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.
In the long run it might be better to treat software as "fast fashion" rather than something meant to last forever.
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.
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).
That is what is wrong.
> 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.
https://www.microfocus.com/en-us/products/visual-cobol/featu...
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.
[1] https://www.historyextra.com/period/ancient-greece/why-do-we...
[2] https://en.wikipedia.org/wiki/Zen_Mind,_Beginner%27s_Mind
Most young programmers are decent, and most old programmers are decent.
Embrace average, and everyone just get the fuck over yourselves already.
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.
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.
That is where rampant ageism really happens. We don't just need old, highly experienced programmers; we need programmers of all ages.
People from that mindset get filtered out. As time moves on, that mindset will be completely eradicated.
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.
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.
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.
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 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.
But yea, there are way harder domains than that.
It’s not about being able to write solid code - anyone can do that. It’s about experience.
You really don't know what you don't know.
[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.
These are on critical services.
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 ;)
You first learn how to program. Then you learn how to spot recurring problems, teach, and right-size your mentorship.
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.
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.
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.
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 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.
This is very false in the embedded space. It may be false in other spaces as well.
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.
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 think programming actually belongs to a category of activity, along with pure math, where crystalized intelligence is the primary driving force.
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
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.
EDIT: inb4 downvotes roll in to your post because it's an uncomfortable truth
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.
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