I'm approaching 50. Just a scant decade away from being old enough to tap my retirement accounts and have the OPTION to retire. These next couple of years look like they might not be fun, but overall it looks like I'm actually going to make it.
For most of my career, I've been told (and I believed) that I would probably get forced out of a hands-on individual contributor role as I aged. During the late-2000's, I even had an early midlife crisis and earned a law degree, expecting that I would need to make a career change into IP or something. That hasn't been the case.
What I think people missed is the compounding effect. The supply and demand for computer programmers seems to double every decade (maybe the interval is even shorter). With each doubling, the older cohorts become a smaller and smaller share of the whole. People look around and think, "There aren't many older programmers here", and base predictions off that observation. However, the more accurate observation would be, "There have been A LOT of younger programmers added here!". I don't believe that it's actually a zero-sum game, though.
I don't know if this human resources cousin to Moore's Law will continue indefinitely, but it's certainly held up through my career. Even when it inevitably slows down, I think that just means you'll see the age cohorts balance out more over time.
I’ve seen a lot of older programmers. They can wind up working as a team of one because they’re productive enough to do the work of an entire team.
I’ve seen this a lot. Hire older dev. Older dev has decades of experience. Older dev creates new product from scratch in a couple weeks.
Another issue is that mentoring is focused on junior devs by senior (6-8 years of experience) devs. So you’re less likely to have a senior dev (6-8 years experience) mentored by a dev with 20 years experience.
I’m kind of in this boat. I’ve been doing this for 25 years now (jeez). Mentoring a dev with 6 to 8 years experience is a pain in the butt (yes. I know. Not all of you).
While I’ve got a pretty good memory, a lot of the times I don’t have a direct or complete answer for their question. I’ll have a tingle of a memory that is similar to their question. So I’ll give them that as a starting point and tell them how I’d approach the solving the problem. But they get frustrated that I didn’t solve their problem immediately. That I can’t point them at a blog post of Stack Overflow answer.
But a dev with 1 to 3 years experience? They’ll take that non-answer and run with it.
And I get it. The 1 to 3 probably has 1 maybe 2 tasks they’re working on. The 6 to 10 (to 15) has probably a half dozen things they’ve got to keep track of. Researching is probably pretty low on their list.
I'm working with a junior dev now and the phrase that I keep repeating is "slow the fuck down". He's completely frantic with the copy and paste. I'm watch him google something, click the first link, paste the code into his project, and when it doesn't work he's on to the next link, paste, repeat. He doesn't even back out the changes he made the first time that didn't work.
I spent hours fixing his code and hand it back to him and it's broken again in a week.
I had to wash my hands of it. The only advice he's getting out of me now is to follow a single tutorial all the way through until he gets that one tutorial working and then compare the tutorial to his code. I'll answer specific questions, but I'm not going to try to mentor him until he's ready to receive the wisdom.
This seems to be what modern software development has degenerated into. In the future, it'll be monkeys playing roulette with Github copilot until something compiles/executes.
No, it's not. They're just inexperienced and it will stop/become more thoughtful as they're gaining experience and learn how the pieces actually fit together.
The reality is that half of the tutorials and answers you can find won't work. Either because they're doing something entirely different or because they're for a tool/framework that's deprecated the functionality.
A beginner won't be able to tell this simply because none of the pieces are known to them.
When a person with more experience finds these tutorials they'll likely know within seconds if a given answer or tutorial is even remotely applicabe, which enables them to be much more thoughtful about what to do.
You'll potentially waste weeks on trivial tasks if you're hellbent on actually fully understanding something right at the start, and if the beginner does this the more experienced ppl will complain how inapt they're.
Honestly, you both just sound like toxic people in that regard and should not be allowed to work with total beginners. Which is fine, but the issue really isn't with the pupil that's just clueless. They need somebody to give them a tutorial and guide which is applicable and they'll learn how that piece works, now keep repeating that until they've got a basic understanding of the system and only then can they work on their own
That sucks. I wish I could say I’ve never had one of these. And luckily I haven’t had one go as badly as yours. The main one I recall is when I had a good manager at the time, and he noticed the amount of time I was spending with the junior. So my manager took it over until they got to more meaty issues that required discussions with me.
While I’ve got a pretty good memory, a lot of the times I don’t have a direct or complete answer for their question. I’ll have a tingle of a memory that is similar to their question.
The same. Especially under pressure. Which makes it virtually impossible for me to pass an oral technical interview.
Agree completely. Reach out to prior managers that you respected and would want to work with again. In the past decade, I’ve worked with the same manager across 3 different companies. All without a loop.
I have 20 yoe but happy to be mentored by someone with much less. There is too much to learn out there, so good chance the less experienced engineer can help me too.
It's crazy. I sometimes get the itch to learn a new language like Rust, but I haven't even come close to reaching the bottom of all the languages I already know. They are inventing new things faster than anyone can acquire them.
To add it's not just languages. I was once assigned to teach Cognos a BI tool that's been around a while. I was given the instructor's manuals to go through. It was then I realised how incredible sophisticated the software was and I also realised most people didn't even use 50% of the software's capabilities. I have found the same with text editors and IDEs. You can use an editor for five years and still continue to discover new features.
I have been programming for over 30 years now, and one thing I consider myself an expert in is bash... hell: the (original) author of bash is someone I have known well and used to work for, and he considers me an expert in bash (which is probably another example of this in and of itself), and I once spent a couple months writing my own bash-compatible shell replacement for various reasons with him on the sidelines cheering me on.
Well: I have recently been teaching programming to a 10-year old kid, and this morning he told me about the syntax {X..Y}, which expands to the range of characters between X and Y. I have likely typed {0,1,2,3,4,5,6,7,8,9} a thousand times and now I know you can write {0..9}. I was floored and have it on my todo list tomorrow to see if that is a new feature or if I simply somehow missed it in the man page--which I thought I had carefully read multiple times and which I additionally have skimmed many times--consistently for decades :(.
This. Completely. I have 38 yoe but I still encounter young people with fresh ideas. Keep that open mind. I have met some old engineers that turned into grumps (don't be one of them) but most of the older technical people I work with regularly find joy, both in their work, and through their coworkers.
the thing that gets frustrating as i age are interviews and code challenges. i'd really prefer a certification that proves i can do xyz which i take once (per year? in my life?). then just decide if you like me based on personality and communication.
i have over 200 repositories etc.
its redundant, and random code challenges that differ from employer to employer prove next to nothing.
20 years ago it was the norm for interviewers to ask brain teasers / riddles in interviews ffs.
edit: perhaps this is my own personal struggle as I did not attend University.
I'm an older engineer too and I am very aware of how frustrating this can be for techs of all ages so I made our screening test less fizzbuzz, do my work for me and gotcha questions and more real world, challenging, engaging and most of all interesting.
Examples include: How would you solve this at a high level, here's some code we know is broken, how would you both fix and improve it etc.
After all, both parties are being screened.
The other upside is that we also get to gauge communication and analytical skills not just production line coding.
Even after doing this, over the years I have seen a good 30% refuse to do it or just ghost at this point for whatever reason. Afterall, I've done it myself a number of times.
over the years I have seen a good 30% refuse to do it
I'll do reasonable take homes, but I'll often pass on interactive coding sessions. I don't like coding in a browser, and I use my dev tools as a major crutch.
"Why did you store that value as a string instead of a long?"
"Because it's a string from standard in and I have no idea what bullshit inputs there will be so I can check it before casting it."
"But the user story said it will be a number."
Well if I had more than 15 minutes maybe I would have been able to gain confidence in the input. Something like that comes from many years of experience getting burned yet it's considered a negative mark. Some of these places are actually selecting for recklessness.
A take home that can be done in an hour or two is fine in my book. It’s problematic when they assume way too much background on the part of the interviewer. I had a take home from a small local embedded devices company want me to write a 2D DCT algorithm from first principles in C (absolutely no use of external libraries or code copied or based on any existing code) and I noped out pretty quickly. Unless it’s something I’ve done before, doing it honestly without consulting any existing code would probably take me days.
As someone who is very “certified” when it comes to cloud, I can tell you that certifications mean absolutely nothing and can easily be gamed. I went through the certifications route only as a guided learning path so I would know what I didn’t know. Anyone can pass a multiple choice certification. I got my first AWS certification without ever logging in to AWS.
But it was never to get a job or a promotion. I was already the Dev lead at the company working on an on prem system and they wanted to “move to the cloud”. I just wanted to get an overview of the landscape.
As far back as 2000, “brain dumps” of MS certifications were a thing.
So I’ve heard. If someone passed the K8s cert, you expect them to be somewhat competent. If someone honestly studied for AWS certifications without experience, you expect them to be conversant. I have nine of them now (out of 10). But just so I can be conversant. It’s definitely not prove competence in areas where I don’t have real world experience.
I have avoided this problem by not interviewing anymore. Every job I have had after my first one has been going to work with someone I worked with before, and they recruited me so I didn’t have to do any formal interview process.
I have had to interview for jobs, but the four jobs I have interviewed for since 2000 were all in response to requests to join companies, either from friends, or (once) from an internal HR employee (and to this day, I have never found out who gave him my name).
So the interviews were more about finding out if I would fit within the team than hard technical interviews. People knew me, and knew what skills I brought to the table.
Your network matters. And if you think it doesn't, stop, think again. Your network matters.
One final note. I have interviewed people. Never oversell yourself on your resume. Don't put down that you are an 'expert' at this or an 'expert' at that, unless you really are. Because you just may end up being interviewed by someone that is. And nobody, absolutely nobody, is an expert at fifteen different unrelated things. Don't do that. I have been doing this for 38 years, and I am pretty good at about five things. And those five things that I am good at have changed on a regular basis since the day I started.
Dang those are amazing connections.
Even with good connections I can only get my CV to the top of the pile and maybe some more leeway from the interviewers (which is a lot!), but never was I just skipped through the whole thing and gotten an offer.
You have some good friends are they are high up the chain I guess.
Well, I have only had 3 jobs after the first one... I tend to stay at places for a while. My first company was shut down suddenly by the parent company, and I was recruited by a consultant we had worked with to join a startup he had joined.
I then joined the next company when the people who started that company started a new one.
When that startup failed, I was going to take a break and maybe start my own company, but a guy who had worked for me at the failed startup invited me over for margaritas and to check out his new company he had joined, and next thing I knew I had accepted a job offer.
I have been at the last job for almost 10 years.
I now have a ton of connections from people who I worked with and they then left the company. I am sure if I was interested in getting a new job, I could put some feelers out and have some offers right away. I have had people try to recruit me, but don't have much interest in leaving my current place.
I don't think my experience is that unusual. It is so hard to find good talent, sourcing from people you have worked with before is extremely valuable.
I think interviews and code challenges have to be be decentralized and unscientific. Assessing likelihood of success in a software engineering role is genuinely difficult; any single well-known credentialing program is going to generate experiences of its graduates being incompetent in the wild. And then no one will trust it anymore.
People's own interviewing styles aren't any more valid, of course, but they operate at small enough scale to escape the kind of scrutiny that a standardized test would attract. People also don't like to admit they're wrong, and might be applying a kind of halo effect to colleagues who have passed their personal interview questions. Whereas people love to dunk on prestige, and will eagerly seize on anything they can count against someone with a prestigious credential.
I've interviewed people with computer science phd's from schools with good reputations that couldn't program worth a damn when it came to some simple algorithm and practical coding questions in person so, I don't have a lot of faith in certs/degrees for this.
Computer science PHD is to professional programming what a food science degree
is to being a head chef: the wrong credential to rely on, even though it sounds
related and is somewhat transferrable.
It a small company not specialized in education and examinations can set a test and deduce if I am good enough to code, then this can be standardized. And there could be many certs: 1. can code, 2. can code c++, 3. understands multithreading
… and so on.
I could see this being ok if the certs were retaken regularly. Passing a cert at one point in time doesn't mean you've retained all the knowledge that cert is suppose to assess after some time has passed. This is essentially what TripleByte does for its process to find good engineers for startups.
These types can't usually think clearly under pressure. Besides, answering coding questions is very, very different from inventing those algorithms. It's a completely different way of thinking. That's why.
But does that mean they're bad programmers? I don't think so at all.
As a young person, we grew up with the internet so we're conditioned to just know the "pointer" to the information and then have to google/search for it.
Now I've learned all the algorithms and data structures at uni too and passed the exams but what remains are the names of them and roughly when they are needed. It may be unfortunate but that's what it is like to study nowadays. It's all about cramming everything into your head and passing. Distractions absolutely everywhere and anxiety that we won't live up to and have the lives our parents had.
Now i for one dislike leet code and coding challenge interviews. I think it's silly, plain and simple. What i would look for instead if i was an employer would be curiosity. Nothing is more important than insatiable curiosity. A curious employee will learn everything about your whole stack in the first week... just out of curiosity. And if they do hit a leet code like problem during day to day work you best believe their curiosity won't let them rest until they've solved it, be if with prior knowledge and experience or without.
I could spend a day doing the hackaton project or I could spend it teaching basic computing to someone who thinks himself an expert and is unwilling to learn. But I can't stop time, so can't do both.
It's almost certain some of then (maybe most of them) would have fared just fine if they were left with the problem alone, not in a high pressure setting like a job interview.
I agree pressure can play a part, but thinking clearly under pressure can be a very important skill to assess in a candidate depending on your company. For a high growth startup, there is often a lot of pressure to deliver effective code quickly. I also think retention of knowledge plays a large part.
I'm currently working on an old cad sort of program, its a mess, 20 years of kludges. Working on it is hard - you have to keep all this stuff in your head and I keep saying why the f did he do that, as expected really. Recently I had to add a new bit and use some computational geometry algorithms, it was like a step into a clear dark pool, everything was ordered and nice, which is probably the world of the phd.
I don't know how you test for the ability to do real world stuff - I always think of doctors, they have a system of proctoring they've developed over the years, where you're judged by your peers and rated accordingly and even then its not 100%. I think this is the only way to do it in real life, but I don't know if programming will ever get to that point, it probably will be necessary sometime - when everything is driven by computers.
No the general sentiment is that the interview process for software engineers suck but almost no one wants to take a chance trying to develop a new way to interview. It’s somewhat understandable though since devising a new process can’t be to people focused less you inherit too much bias from the interviewer, nor can they be boiled down to a objective metric or else people may fall into inflexible dogmatic practices that use metrics that don’t directly or accurately measure a candidates ability to perform the job applied for
> almost no one wants to take a chance trying to develop a new way to interview.
I'm guessing your in the under 40 camp, but interviews did used to be better.
In the early days of the startup explosion interviews where much better. The biggest signal at the time was having an active github profile or otherwise existing portfolio of code. The strongest signal back then was serious contribution to any open source projects (strangely today that almost seems to count against you). It also wasn't required that you had these, but they were a very strong signal.
Interviews were largely technical conversations, to see if you understood the concepts, and even more importantly, it was okay if you didn't know. I remember being asked a question about TCP vs UDP. I didn't know much networking at the time, and explained what I knew about TCP but admitted my understanding of UDP was basically non-existent (admitting ignorance used to be a huge plus back then). The interviewers then explained how it worked and asked if I could explain when and why this would make for a better solution than TCP. I answered about the obvious application to media streaming and passed. Interviewers didn't care that you knew everything, they wanted to see how you think.
Even the original predecessor to our current leetcode nightmare, fizzbuzz, was never supposed to hard it was meant as a basic sanity check. There were some devs who had just followed the flow at some big bank and literally couldn't code on their own. Fizzbuzz was just to make sure that given a blank page you could implement basic code.
Of course as tech started to boom, so did the bootcamp/interview industry. People were trained to do fizzbuzz, instructed how to create a github repo filled with meaningless, half started project (or forks of other projects), and people where told how to flood OSS projects with minor pull requests so they could claim to be contributors. Then companies wanted to be like Google and have hard white board challenges.
Then you had a generation of engineers that never knew any different and largely had forgotten (or never known) how to assess technical competency anyway than through a series of hazing rituals.
That second article is interesting in this conversation because it's main contention is that the vast majority of any applicants to any position you're trying to hire for are going to be terrible.
Which is the phenomenon seen by others as well and discussed in Atwood's 2007 one.
They don't really talk about the Google style DS/algo problems, so yeah, seems like those became popular later.
But it suggests the hiring experience for companies has long been awful.
The sort of experience you had - a good conversation about a detailed relevant technical area - is something that I've never personally found common when trying to hire. Most candidates still aren't great if you're looking to do even moderately greenfield development (even if not particularly interesting - just being able to put together a decent scaffold of an idea).
Leetcode - the site - is an interesting phenomenon because it's full of problems far harder than any I've seen in practice at FAANGs and similar. Stuff I've encountered in the real world seems to fall into the Easy or Medium buckets.
After being at a BigCo and hiring some people who aced whiteboard coding and failed on simple everyday things, though, I certainly would never again use something like that as the only factor.
That’s truer and truer the more generalized the position/hiring pool. “Developer at GiantCo” will end up doing leetcode interviews by default. Cofounding as a technical founder will be pretty much all about personal fit. Between these two extremes is a wide continuum (smaller companies, tech positions at non-tech firms, freelancing, consulting…) that’ll have different processes for finding a fit between someone with a problem and someone proposing a solution.
If you truly hate the way interview processes have run for you, it’s worth considering if you feel strongly enough about it to seek a different fit in the market. You might not, and that’s fine! But alternatives do exist.
I think Leetcoding is a worthy investment for career. Why not .
I understand that it feels like its waste of time with no practical use but the upsides are that they make job hopping trival because you know what to expect and feel confident.
I think its a tiny investment for big returns. unparalleled to any other activity you could invest your time in.
> unparalleled to any other activity you could invest your time in.
Huh. Never heard that before.
I invest my time in writing "shippable" code. Even my "farting around" projects are done in a manner as if they were to be released by a Fortune 50 company.
That means that Every. Single. Line. Of. Code. that I write is "ship" code. There are a number of projects that I've stopped working on (I archive them, but leave them out there), and a few that were never really meant to be sent out to fend for themselves, but I still make the effort to write tests and documentation for them.
I'm so used to delivering software, that I've almost forgotten what it was like to play around; which is actually a bit of a shame. It could easily be said that I "take things too seriously." I can tell you that my employers liked it, though.
My GH Activity Graph is solid green, and I wouldn't dream of "gaming" it. I don't especially care whether or not anyone thinks I'm "l33t." I'm an old fart that has no intention of working for anyone, ever again. I write code for myself, and that I want to see. Most of the folks that I care what they think of me, have no understanding of my tech work, and that's fine.
It makes me feel good to make good, well-tested, well-documented, well-architected code that solves problems.
I guess you could call me a "completionist." I like to finish stuff.
I have to agree with parent comment. Leet code interviews, while sometimes obnoxious, are still good exercises. I have learned a lot of nuanced takes from a leet code interview with an interesting question.
Right now, I'm working on a data parser for a backend API that fetches a JSON response, using the built-in NSURLSession stuff, turns it into a Swift Dictionary, then I sort through that Dictionary, and emit a bunch of Swift struct instances for use by the API consumer.
The reason for this, is because the API that I wrote about seven years ago, is giving us performance problems. I wrote about that in this comment[0].
The NSURL stuff has all the sockets and whatnot, as well as all the transport stuff. I've written that stuff before, but I guarantee that the deep geeks that wrote the system have done a far better job of optimizing that stuff, than I ever will.
The JSON parser (built into the OS, but I may think about maybe licensing another one, if this doesn't do what I want) has all the recursive-descent, tree-crawling stuff in it, so I don't need to worry about that. Since this is a multi-threaded system, almost every school algorithm is worthless, but I guarantee that the deep geeks that wrote the system have done a far better job of optimizing that stuff, than I ever will.
I want to get the hell out of this API, as soon as possible, and return to writing the UI stuff that will make my app sing.
The API is being developed as a standalone SPM package that will work on all the Apple systems (iOS, iPadOS, MacOS, WatchOS, and TVOS). The one that it's replacing only worked on iOS. No excuse. I know better, now. I'll also be structuring this to be a lot "swiftier," and more "reactive" than the original API.
The app is a native Swift UIKit app. It's a big mofo. At its peak, it was over 40 screens, but I'm trying to get it down to half that. I've been working on it for a couple of years. It's had a couple of pretty massive pivots, in that time.
UIKit is a big framework. It takes years to learn. I'm looking forward to SwiftUI, but SwiftUI is not at the point, where I'm comfortable committing to a project of this scope.
I've been working with UIKit since 2012. I barely understand it, and they keep adding new stuff, as fast as I can learn it.
Swift is an excellent language. Like every language, you can get the basics down in a few weeks, but it takes years to get the advanced stuff down.
I've been working with Swift since 2014 (the day it was announced). I speak it without an accent.
The project I'm working on has been a wonderful masterclass in Apple iOS development. I also wrote a fairly massive PHP backend, but that was years ago, and it is, I guarantee, not as cool as a really good PHPista could do. That said, it works great, is maintainable, secure as hell, and fairly well-structured for scaling and extension.
The app is gonna be great. Its approaching ship (still a ways off, but we can see the harbor lights, from here). I've been releasing it on TestFlight since it was a month old. By now, I've probably made over 800 TestFlight releases to the team. That's how come we can be so confident in the UI and the Quality. It gets banged on a lot.
But maybe I'm doing it all wrong, and I should stop working on this to practice leetcode.
>But maybe I'm doing it all wrong, and I should stop working on this to practice leetcode.
Junior here and not as experienced as you are but I resonate with a lot of what you have written so far. I'm more of let my work and projects speak for itself. I also hate leetcode or code challenge kinda interviews. So far I haven't have to take any to get a job and I plan on never taking or doing any. If I see that an interview involves such I will reject it. I can accept a decent take home assignment or technical questions in areas that I will likely encounter on the job.
Just be aware that by doing so you are ruling out a huge swathe of companies, typically the ones who pay much more than the rest [1]. It’s fine to do so, money isn’t everything, but I think it’s worth being aware of the trade off. FWIW I think any reasonably competent developer can master Leetcode to a good enough level in maybe a few months (outside of work)… The Manning Grokking Algorithms book is a nice simple intro.
Bad move imo.
You're only a junior, you have your whole career ahead of you. You're ruling out more than 50% of companies by deciding not to do live coding on an interview.
> But maybe I'm doing it all wrong, and I should stop working on this to practice leetcode.
You're not "wrong" per se. If you want a pure Swift job it would be very reasonable if the hiring company tested you on your very broad and deep Swift knowledge.
However, if you ever wanted to do anything else job wise you'd be screwed.
Leetcode gives you a chance to become a Java/PHP/C++ dev somewhere. That's the only plus for me.
I'm mostly a Ruby/Rails dev experience wise and I get a real chance at different stacks because their hiring process is Leetcode (or something of the sort) and general design questions.
So sure I'll never know as much about Swift as you but I do think that a hard working engineer who takes his craft seriously can pick it up and become productive in a couple of months. Not an expert, productive. I can join your company/team and then someone like you can make sure my code doesn't suck. For many companies that's good enough. Others can't or don't want to mentor anyone for more than a week or two so they only accept someone who fills all the requirements of their stack. Mostly startups, and in general not my cup of tea.
I love this, and I’m stealing it. it’s a perfect description of competency in a language, imo.
I absolutely understand the emphasis on shipping, and i actually have recently come to lament some of my unshipped projects lately (I’m in a phase of finishing instead of starting projects myself, and sometimes have felt like I haven’t gotten to ship anything in my software career, but that’s another story for another day) but part of the core skills I attribute to allowing me to finish are the same ones leet code interviews helped me polish. how one works on a low-level data structure is one of the core aspects of software engineering i examine in a new hire.
What I think I’m trying to say is, I don’t mean to stop working on shipping a project to focus on leet code toy problems, but rather that a lot of leet code interview problems have given me better insights on how to focus and solve problems im trying to ship. I have found great value in going back and rehashing leet code interview problems and turning them into tiny libraries after i was given them. So much so that I’ve turned it into an exercise. I’ll have to write a full post about it sometime, but writing tiny libraries has been one of the best things I’ve done for my technical skills.
> I’ll have to write a full post about it sometime,
I'd read that.
> but writing tiny libraries has been one of the best things I’ve done for my technical skills.
I do that all the time. When I get to a bunch of code that I think has reuse potential (like, say, a backend connection SDK), I break it into a standalone GitHub repo, set it up as an SPM package, and give it The Full Monty for testing and documentation. The testing code usually dwarfs the implementation code, and the documentation is...well, you can see for yourself. Here's a few of the packages that I've written: https://riftvalleysoftware.com/work/open-source-projects/
I usually take a few days off the main project, write, test, document, and release the subproject, then re-absorb it into the main project.
If you’re looking to get hired as an individual contributor somewhere else, maybe you should. But judging from this and other posts of yours, you’re not, so you’re probably not doing it wrong.
It’s just that when interviewing, it can few easier to evaluate some algorithm puzzle than to figure out what it means and whether it’s true that “the app is gonna be great.”
Well, that screed I wrote, is a fairly typical "geeky conversation" that can be invaluable, in an interview.
I used to hire pretty senior-level engineers. They would be writing C++ image processing pipeline code, to some insanely exacting standards.
My technique was usually to get them relaxed and comfortable, then start asking them for stories about the projects they've worked on. It was always a joy, when I could get them to start chattering, like the post above. I would look at the enthusiasm, and the passion, as much as the technical detail. I'd love hearing them talk about discovering problems, and how they addressed them.
I currently started a basic iOS project with SwiftUI and it is just utterly painful to work with. I kinda hate mobile development because of this reactive roadmap shit. Why would anyone code a UI. I’m old now and I realized I’m getting resistant to changes.
There's a lot of similarity between that, and UI work.
I trained as an artist, way back in the Paleozoic Era, and that gives me "airs" about things like graphic design, and data presentation. I've spent a good part of my career, unlearning that crap. I'm usually best off, leaving the defaults in place, if possible. I write about that here[0].
I think that UI needs to be treated as seriously as possible. It should not be an "also" thing. I think it needs to be the starting place for the work, and I tend to develop UI pretty quickly, in my work.
I feel like SwiftUI still needs a lot of fine-grit sandpaper. I have every confidence that it will get there, but I don't feel confident in committing any project at scale to it.
I’m not really up to doing that kind of write-up. However, I did write this series[0]. Some of it might be a bit “dated,” but it probably has what you want.
There’s an excellent book[1], called “Advanced Swift,” by Olle Begemann, and Chris Eidhoff, that gives a far better breakdown of the more intricate parts of Swift than a simple bullet list.
Like many languages, Swift is a deep rabbithole. Heck, you can get lost, just in the way it handles strings[2].
I think you’re missing the point of the parent post. In terms of an investment in your career, if you’re optimising for money, it’s hard to argue that learning to do Leetcode can have huge returns. Whether it actually makes you a better developer is a different issue entirely
> I think you’re missing the point of the parent post.
It's also possible that I didn't "miss the point."
They did ask "Why not". It may have been rhetorical, but I pretended that it wasn't.
Of course, like all these types of things, I have my own approach. It's fine, if others don't want to do things the way that I do, but I'm not into playing "Me Big Man on Campus" games. I just talk about the way that I do stuff, and my own approach.
For me, I can't even imagine "job hopping." I stayed at my last job, 27 years.
If "job hopping" is someone's idea of a career, then I guess leetcode is the way to go.
But if we want to stick around, that means that we can't just have a veneer of competence. We need to actually have it.
Even though I had other means to get into BigTech and still stay hands on technical, if I didn’t, I definitely would have spent 3 months “grinding leetCode” to get a six figure increase.
I’m lying, I would have hated working for any large tech company as a software developer after spending decades at small companies.
Totally agree with this, although I do see some more alternative methods used by non FAANGS (e.g with f5 it felt like they actually tried to determine my actual knowledge as a SWE). But solving a few Leetcodes every now and then (even outside of interviewing season) is probably a very profitable habit.
In theory that’s what TripleByte was supposed to be, but it didn’t really work out in practice. At best being screened by them got you past an initial screener call but you still had to go through the full gauntlet of interviews at most companies. Then they realized they weren’t making money and started doing shady stuff with personal data: https://news.ycombinator.com/item?id=23279837
The difference, an engineer is told what to build and tries to do that.
A programmer is told what to do, and half way thru development they have the boss show up and say 'I just read of this brilliant idea in BusinessWeek, lets add/change the code to do .....".
Except it's usually more "I just read about fantastic technology X, we need to use that". Ignoring the actually problems we have and whether technology X will solve them in any way at all.
"For most of my career, I've been told (and I believed) that I would probably get forced out of a hands-on individual contributor role as I aged."
Programmers are in a bubble. Head over to the local grocery store. The person bagging your groceries is 63. There is no retirement plan for him - as well as most Americans. These "old" people will end up working until 70, on their feet. If I can find someone to pay me to write CRUD apps all day in whatever hipster framework, I am fine with that, no complaints here. Beats working at HomeDepot.
A bubble as in we are not cognizant enough to recognize the benefits of investing in our skills and education so that we aren't bagging groceries at 63, or a bubble as in we should not expect our current ratio of compensation vs skill to hold out forever?
I had an office mate whose dream was to retire to the tools desk at HD.
While brutal, there is something to working later from a health perspectice. When I was young, retirees played tennis and golf but I dont see as much of that in my cohort.
I'm the other side of 60. Quit my job and took up contracting after the founders of the firm I had been employed by for decades sold out to a firm maybe 100 times the size. I stressed out wondering if I could still cut it with the young guns.
I was contracted to create the backend for a SaaS platform, from scratch. It runs on AWS, using a lot of AWS services, and is django based. The thing is - I'd never used AWS before, nor django. (I'm not sure how they chose me, to be honest.)
Picking all this new stuff up at my age it's nowhere near as easy as it used to be. But the process of writing software is not just learning libraries - and the rest I have down pat now. I immediately set designing the data structures and databases, wrote a spec based on those structures and got the spec reviewed before I started (I had to pound the table to make that happen). Then head down, arse up writing code as fast as I could. I had to deliver it all without an AWS platform to run it on, or a front end to drive it - but you don't get to my age without knowing a thing or two about unit effective testing.
Then after delivering, I was told it had all been changed by the UI guy, so massive refactoring. Unit tests are worth their weigh in gold when that happens.
All the while I was told I was talking too long, which ramps up the pressure and self doubt even more. (But with me muttering - what did you expect when change the UI I had based the spec on without telling me, ffs.) Boy do you lean on unit tests when that happens.
Then the first code drop, which was few tens of thousands of lines of code done in a few months. Which if you crunch the numbers, was 20% of the size their existing code base, delivered by one guy, in 5% of the time it took several people to develop the existing thing. Bug rate after unit tests was below 1 bug per 5k LOC.
Turns out they were begrudgingly impressed by that. So right now it seems I still can match it with the young guys. Yes learning new stuff is harder and slower, but I make up for it very efficient software methodologies honed over decades, which when I can apply them for a few weeks straight leave them in the dust.
The way I feel now it seems when I'm 70 pulling that sort of stunt will be impossible, so I don't have too many more job changes left in me. But at 50, you have a while to go yet son.
The number I saw was something like every 5 years the number of programmers doubles. So half if all devs have less than 5 years experience. And since most new devs are more likely to be closer to college age than retirement age devs tend to skew younger than 40 (probably by a lot).
I ran numbers from the BLS on occupation data a few years back. If you look at the number of programmers 25-35 in 2000 and the number of programmers in 2020 aged 45-55 you see a real and substantial decrease in absolute terms. The decrease is much larger then other professions, so its not attributable to a cohort just exiting the workforce in general.
There is also a massive increase in the number of 25-35 programmers in the same time period.
My interpretation is there are definitely forces that push against older programmers staying in or re-entering the profession, but they aren’t as severe as they appear to be just looking at the raw numbers. Generally, programmers who want to remain the profession are going to be about to, but it is harder to be a programmer over 40.
Here's [1] a data analysis looking into the phenomenon:
"Professionals with higher cognitive ability drop out of STEM careers earlier and faster", "High-ability workers are faster learners, in all jobs. However, the relative return to ability is higher in careers that change less, because learning gains accumulate"
Some of this is how easy it is to transition from programming to something else compared to other professions. Jumping from building some piece of software to being the expert on it or managing programmers to managing projects etc.
This is especially tempting if someone’s skills start to diverge from what’s in demand.
The number of "jobs" added doesn't quite double, but if we think of it as "for every 4 that retire, five take their place" it would definitely feel like what you're saying.
> I even had an early midlife crisis and earned a law degree
Same. In my case, I paid my way through law school doing software development contract work, which paid better than entry level lawyer work. Now I do a mix of software consulting/contracting and IP technical expert work (patent/copyright infringement analysis, claim charts, etc). I enjoy doing both kinds of work, though I really enjoy legal writing and I'd like to get more into IP litigation, writing pleadings, motions, oppositions, etc.
At 64 years I am still going strong. I consider myself blessed that I have landed a position that allows the to be the leader (I manage a small team) and still be hands on with everything: Architecture, desgin, coding, infrastructure, cloud engineering, DevOps engineer, DBA, the list goes on. It is a Goldilocks job. The technologies that we manage and master are miriad. We are a small company and my team owns the entire space. All my years of knowledge and experience enable me to be coach, mentor, and teacher. Over the course of my 44 year career I have played every instrument in the band. I manage with a socratic method which my team enjoys. Because I have been a life long learner, I have sought out and explored new technologies with eagerness and hunger. This enables me to lead the team to adopt some of these technologies in usefull and vaulable (to the enterprise) ways. The team absolutly enjoys learning and applying new and emerging technologies. I could not have asked for more from what will probably be the last gig of my career. I don't intend to retire until 70 (assuming I am that lucky - you'll know what I mean when you get here). I am having so much fun I wish had 30 more years ahead to enjoy what comes next. I always like to say: It's good work if you can get it - not everybody can.
People who can manage and code (architect, etc.) are truly rare. I'm not quite at the same age and only play the guitar. Like the article author and where we differ, I am very skeptical of new technologies, if I can't find a use for it in my personal software projects without having to hold my nose, there's no way I will recommend it for work.
> People who can manage and code (architect, etc.) are truly rare.
I disagree with this. I think there are a lot of people who don't like being a leader for lots of reasons... but every time I've promoted a reluctant leader it's been magical for that person and for their team. A lot of times the people that self-promote and like to be in charge should never, ever be given athority.
> I am very skeptical of new technologies
I used to think that way until I realized that in a lot of cases, we've been re-inventing the same concepts in computing since the 1960s. I think a lot of the re-invention is really being driven by hardware capabilities, languages and fashion. We're seeing it with Rust right now - let's rewrite all the things in Rust! Underneath it all, though, the payoff for using new, less capable tech, is that eventually it will pass up the old in a very meaningful way - and when it does, systems build on the old are washed away.
> but every time I've promoted a reluctant leader it's been magical for that person and for their team.
I was hired at my last job by the then new CTO to lead the “cloud application modernization” effort as they were pivoting to providing access to micro services to large health care companies.
After being somewhat successful at it, he offered to make me a team lead (been there done that). I told him in no uncertain terms that I would quit first. We had a great working relationship.
I now do basically the same thing in the consulting department at BigTech as a middle level hands on consultant.
I asked a year end could my position be considered a “terminal position” or would I need to work toward a promotion. My manager asked me why. Again I was very honest. I needed to know because I would be looking for another job before seeking a promotion. He said it could be a terminal position,
> we've been re-inventing the same concepts in computing since the 1960s. I think a lot of the re-invention is really being driven by hardware capabilities, languages and fashion. We're seeing it with Rust right now
I often hear the argument that there is nothing really new in programming and that everything was already done in some way or other back in the 1960s.
I completely disagree with this and find it harmful. There is genuine innovation and new research happening in computer science all the time. The example you gave, the Rust language, is based on linear type theory that was first developed in the 1990s. Nothing like it existed in the 1960s and that is why it offers real improvement to software development.
Today, software development is slow, buggy, expensive and late. We owe it to ourselves to continue to research and search out ways to improve our craft. And this is happening. Newer programming languages and tools DO incorporate innovations from recent computer science research and are better for it. We should celebrate this rather than cynically pretend that all computer science research halted in 1969.
> > People who can manage and code (architect, etc.) are truly rare.
> I disagree with this. I think there are a lot of people who don't like being a leader for lots of reasons...
Note that you are talking about different things from OP.
OP was talking about managing, you are talking about leading. These are two very distinct skills. Sometimes you can find both in the same person, but these people are few and far between, since each of these roles is already a full time job.
> OP was talking about managing, you are talking about leading. These are two very distinct skills.
Everything I've experienced in my professional life has taught me this: managers who can't lead can't manage, and leaders who can't manage cannot lead. Never once have I worked for a manager who didn't see themselves as a leader, and never once have I met someone who called themselves a leader who wasn't management.
People who are stellar managers, have extremely high empathy and EQ, understand their engineers, prop them up, help their career, guide them toward both professional and personal growth. They also did not have a single ounce of leadership or charisma in them, very low technical chops, no vision, and not interested in providing team leadership.
I've also met stellar leaders, visionaries, who inspired, entranced teams with every single word that came out of their mouth. They provided short and long term directions, technical and product guidance, motivation. And they were absolutely terrible human managers. Could not place themselves in other people's shoes. Didn't really care about managing the career or growth of people on their teams. Were only focused on matters that did not involve any human feelings.
These kinds of people both have their places and they complement each other wonderfully.
And sometimes, you find these two very distinct, polar opposite qualities, in one single person. But like I said, this is much more the exception than the rule.
And of course, the reality is that most people lie on a spectrum between these two extremes.
You have provided a wonderfully elegant description of the two ends of this spectrum. Spectrum is a perfect term to use becasue technical leaders who become managers exist on that spectrum in very dynamic ways. Everyone is surrounded by 360 degrees of team members who have different perspectives, expectations, needs, wants, etc. No one can be all things for all people at all times. For my own experience, depending on who you ask - my peers, my leaders, my reports, they will all have varying opinions of how I land on that spectrum and what it means to them. And if you ask this month and ask again next month their perspective may change both positively and negatively. You have to keep trying and growing and learning. You also have to be agile and flexible. Let go of the past and focus on the future. Assume best intentions about everyone. There is no perfect. Its all about the journey.
Leading and managing are two separate skills there are plenty of tech leads who neither have to nor want to deal with managing people, 1x1’s, worrying about others career development, etc.
A leader can lead initiatives just via building relationship and having expertise without role power or any reports.
"People who can manage and code (architect, etc.) are truly rare."
It's not that difficult if you actually can make decisions quickly. It only gets difficult once you are in a bigger company where you have multiple more or less competent stakeholders and every decision get accompanied by multiple meetings.
Very little of what we do as developers or software engineers is transactional. This is very creative work we do. So I don't take status about anything that they are doing. Rather I discuss all aspects of the problem they are trying to solve. Or ask questions about how they approach solving those those problems. I usually enter the conversation with the same verbal queue: "indulge me while think out loud about this....". We discuss concepts like technical debt or design patterns or junky data in our database and how to improve data quality. I also deliberately avoid creating artificial time boundaries. Everyone knows I prioritize quality and stability. (faster, better, cheaper - it's always better)
Socratic approach has something to do with asking questions instead of giving directions. I guess, instead of saying "You're an idiot if you think this works in concurrent setting...", one should say: "What do you think would happen if we run this concurrently? Are you an idiot?" :)
I found I lost interest in vapid work. Programming is still fun, but it's a big challenge to find a job that is fulfilling.
When I was younger, I'd work on whatever. Then everything started sounding like yet another get rich quick company, and is that what I was giving up my life for? Just to move little green pieces of paper around?
The most appealing thing I'd seen recently was a company that wrote software to help maximize farm yields. At least there was some real, effective benefit for a great many people.
It's like the goal of the company gradually became more important than the tech or money. And altruistic companies are very rare.
But I always really wanted to teach, so that's what I do now. Pays about 40% of what I'd make in industry, but I get to geek out all day and do work that benefits the world.
> The most appealing thing I'd seen recently was a company that wrote software to help maximize farm yields. At least there was some real, effective benefit for a great many people.
After my graduate work I am the opppsite. I realized that meaningfulness is not a sufficient condotion for enjoying my work. The tasks I work on and my coworkers make a much larger impact on my happiness. Whether I work on something "stupid" or "vapid" matters much less.
I worked on some really vapid projects that were technically very challenging and got to work on them with extremely talented cross functional teams and still felt like crap doing them. It's fun when you're in the thick of it but I feel no joy or satisfaction looking back on any of it. Working on meaningful projects is the only thing that does it for me now.
Coworkers who are pleasant to work with make all the difference to me as well. Smooth communication, trust, and a bit of comradery can make meaningless work go by quickly. Politics, micromanagement, and rivalry can make even logging in a chore.
Another option - if you can manage arranging it - is working part-time (whether half-time or four-days-a-week rather than five), and spending the rest of the time working on the software which you think _really_ needs to get written. With some luck and effort, these two branches of your work can even relate (but then you need to be careful about the IP clauses in your contract).
I agree, programming is still fun. Problem is my job has changed due to my age and experience and has migrated into something I don't want to do or can't do that well, managing others and the project as a whole. I get to do less of what I do and what I do well.
What do you teach? Like computer science at a college? Or something else? How did you make the switch? Was thinking about somehow doing some casual teaching as a step back from a corporate programing career for a bit
Computer science. (I have a BS and MS.) I taught at a boot camp for a few years, and now teach full time at a state university.
I kinda fell into it. I wrote some guides that were popular, and the head of the program at this boot camp was copying my examples for content (I had placed the code examples in the public domain, so he was acting ethically, don't worry), and he stopped and thought, "I should call this guy." They were a startup and needed folks to teach. I had just left the company I cofounded and was drifting for a bit, so it was good timing.
The university is in the small town I live in (about 100k population) and I organized a tech meetup here, and met the head of the CS department that way. That ultimately led to me being hired recently.
For casual teaching, be a part timer. There are lots of night courses that need teaching.
Private boot camps should pay around $90/hr. Adjunct positions at universities probably pay about $1000/class/month. It's really not good money, but it's good experience. I taught a couple quarters as an adjunct at the university and the positive student reviews I gathered contributed to me getting the job, for sure.
Lol I just noticed the user name. I've used what you've written in the past.
That's cool though, 90/hr a works out to a little more then my base rate at my last job so not bad. I don't have a bs let alone a master so I'd guess a university wouldn't want me to teach hah. Thanks!
Not this thread's OP but I can answer - I studied CS at uni, graduated in 2006. Worked for 12 months or so, no more than that, in a couple of smaller companies, and it didn't really click (at the time, I found the work uninteresting and couldn't see what progression in said companies would look like). Went into teaching secondary school (UK, ages 11-18) and am still doing just that. As mentioned above, I get to find out about and discuss geeky things with young people with whom I have shared interests (mostly!); on top of this, I get to run extra-curricular activities with them and do things like chess, golf and board games - it is very rewarding, although not really in a financial sense!
I'm just over 50. Here's ultimately what I think about aging and programming:
Programming is fun. I enjoy it now, more than I ever have. Three times I've created software that has built a business and livelihood for others. That is super satisfying, and at the same time, usually the source of things that are not as fun as programming (taxes, accounting, lawyers, nasty people).
When I run across other programmers my age, I see a lot of unhappy people, and that is kind of sad. A lot of the unhappiness comes from one of three places:
* Not leaning new things and discovering that the isn't demand for what you did in the 90s and 00s. Career prospects are dim, and bitterness sets in. It's easily solved by picking up something new - but be careful, new doesn't mean things 15-20 years old. So many people jump out of one old tech into another one that is about to be old.
* A lack of interest in leading, and being hypercritical of leaders. Here's the deal: if you leading the team, you pick what you want to work on, and you pick how you build. If you are just on the team, you'll always be on the wrong side of decisions. It's easy to lead a small team, and experience is really the backbone of really, really great small "l" leadership.
* Pathological drive to be correct at all times. You know, they person that can't let the smallest mistake go un-punished, every bad decision second-guessed and being willing to die on the hill of correctness over the smallest mistake. This drive makes you good a programming, but it makes relationships with others terrible, and leads to being isolated, alone, passed over and unhappy. It's really hard, but learning to pick your battles and understand that battles can be won and jobs lost really goes a long way.
That said, there's an awful lot of aging, talented, experienced developers out there that are doing great things, and having fun doing it. Find a way to keep it fun.
Programming fun because you find SOLUTIONS all the time. You find better ways of doing things. That is the nature of it because there is no need to write the same code twice.
Wow. Just turned 52. Love coding. Love building useful/meaningful things.
Your three paragraphs read like someone climbed inside the library of my head and just started reading all the thoughts there at once. I struggle or have struggled with all 3 of those. Especially the latter 2.
Several reasons for ageism sometimes missed. This from someone whose been discriminated against, who has hired, who now owns a company & who was also a recruiter.
__I don't agree with this__ just laying the reasons out for clarity sake:
- Hiring managers don't consider themselves ageist, but opt for younger employees whom they think make a better cultural fit. You can blame the 'work is my social life' culture that emerged in the 2000's and that persists today.
- Hiring managers don't want to be ageist, but they've had or heard of bad experiences where disgruntled or non-performing employees abuse the EEOC process for financial gain and retribution. Very well intentioned rules, designed to protect certain cohorts of employees, doing the exact opposite as is often the case with Gov regs.
- Hiring managers (usually fixated on 'new tech') who fear diminished learning, adoption or performance capacity in older employees.
- Money. The perception that older employees cost more in wages and benefits, without much thought to efficiency gains that accompanies gray hair.
I was age discriminated against by a well known SAAS provider, who used a 2014 interview process to extract a detailed roadmap and ideas for product growth from me, and then ghosted me. I've watched as they've (badly) implemented the specific of my roadmap the past few years, and I chuckle. 100% my fault for giving up too much value in the interview process, but it was tough time and I thought I really needed that job.
> Hiring managers don't consider themselves ageist, but
> Hiring managers don't want to be ageist, but
I classify this into the "I'm not a racist, but..." bucket.
> Hiring managers (usually fixated on 'new tech') who fear diminished learning, adoption or performance capacity in older employees
This is the textbook definition of what ageism is.
Conclusion? They are ageists, plain as that. They may not consider themselves to be, or want to be, but they still are, because ageist is as ageist does, and it matters jack what appearances they want to keep or what they think or who they perceive in a mirror.
I won't address "performance capacity" directly since it's too broad and vague, but it is plausible that there is diminished learning as we age. Think about learning new spoken languages. There's evidence to back the idea up in that context [0]. At the same time a 40 year old will likely have a higher proficiency at their language(s) than a 20 year old. This analogy exaggerates the idea (the trade-off) but I don't see why it wouldn't apply to programming languages as well. And this isn't ageism.
You're ignoring that most "new" language problems have significant overlap with things already experienced, and there's only a minor translation issue, rather than a learning new things from scratch issue.
A lot of programmers who are 35+ can struggle to find further opportunities as the more senior you are the less available those opportunities are and the more expensive you are. Lots of companies only want young people who are naive and have limited distractions outside of work. So, really, programming as a field is front loaded and the longer you stay in the business over 35 then the luckier you have been. But make sure you have an effective exit strategy to support yourself and your family when the boss doesn't like folk older than him.
I very much think this is limited to the startup / work fast and break things style of companies. Always work available for sr. people at large established companies, especially fortune 500. Specifically companies where tech is not the core business product, many of them are attempting to modernize their systems. They pay pretty well too; not Google / Amazon level but on a pure salary basis many probably pay comparable to Microsoft without the shares of course. They do have a good 401k match though. A good salary for 95% of tech people.
I am early 40's and have had no issue finding work and am currently interviewing others to come work with my group in a solution architect / tech lead style role and they are all my age. I have never interviewed for a job and not gotten an offer, regardless of age; with that said I'm not interviewing at startups or places I feel really wouldn't allow me a family life. I get the offers not because I'm incredible, I'm not, but because I know my lane and skill set and stick to it.
It was even easier for me to find work at smaller companies the older I got. There were always companies that really needed someone who could help them mature their processes, who they could put out in front of customers, who knew how to work with sales, who they could send off-site and talk to their customers tech departments (B2B) etc.
It got to the point where my “interviews” were more just sitting down with directors/CTOs and talking like adults about how I would help them solve their real world business problems. I haven’t done a coding interview in over a decade even though I have been hands on all that time - across five jobs
After some frustrating experiences applying and interviewing for jobs at the kind of startup-sized companies where I’ve spent my entire career, and fearing that my age might be a factor (I’m about to turn 40), I applied on a job at a Fortune 500 and had an offer a few days later.
The pay, benefits, and work/life balance are excellent, to the point that I have some regret over not exploring this avenue sooner.
Oh, and now I’m younger than most of my coworkers again. I don’t think ageism is a thing here.
The older I get, the more I think it is not the company itself but middle-managers.
Managers with an authoritarian streak will have trouble handling experienced developers that objects to non-optimal designs and processes.
It is much easier for such a manager to handle young naïve developers that gladly accept to work 5 times as many hours as a good design needs.
Software don't work well with an "do as I say, no matter how stupid it is" approach. I think that is why Silicon Valley (and Europe) has much greater success writing software than asia/India.
I manage a couple of developers that are in their late 40s. It's great. I just say, "hey, can you handle this complex, ill-defined task?" and they get it done right, the first time. No real management necessary.
An older, grizzled, battle-hardened engineer is one of a manager's best assets.
I keep hearing this. I’m 48 and between the time I was 34 and 46, bumping around in your standard enterprise corp dev jobs, I found jobs relatively quickly - the shortest time was 4 days from starting to look to having a job (corp dev at the time a F10 non tech company), the longest being two weeks. Every time besides the first, I was juggling multiple opportunities and had three offers. I change jobs 5 times during that time period.
In hindsight, until the last two in 2016 and 2018 they were just journeyman CRUD jobs with the last two being hands on dev lead and de facto “cloud architect” respectively.
I just got my first job in $BigTech at 46 two years ago. It’s not officially a “software engineering job”. But for all intents and purposes I’m doing the same type of work I did at the last couple of jobs - gathering requirements, presentations, development, and a shit ton of yaml, HCL, PowerPoint slides, and diagrams.
I’m sure at 48, I could contact my network of former coworkers, managers, recruiters and someone would give me a job even if it were just a standard .Net journeyman developer again.
If you’re still randomly submitting your resume to an ATS trying to prove yourself to companies by reversing binary trees on whiteboards while juggling bowling balls and riding a unicycle on a tightrope, you’re doing it wrong at 40+ years old.
> If you’re still randomly submitting your resume to an ATS trying to prove yourself to companies by reversing binary trees on whiteboards while juggling bowling balls and riding a unicycle on a tightrope, you’re doing it wrong at 40+ years old.
I did that at 45 and landed an interesting job at FAANG (and I'm not the only one). I think it's a bit contradictory to think old programmers are still as capable and sharp as 25 years old, and at the same time insisting to be judged on different standards.
I didn’t randomly submit my resume to get into a FAANG at 45. When the recruiter reached out to me about an SWE position (that I wasn’t interested in). I kept talking to her and she directed me to a related remote job that I was interested in (cloud consulting - enterprise app dev/cloud architect).
> the recruiter reached out to me about an SWE position (that I wasn’t interested in)
Then it's your preference not to be a programmer. My point was that it's also possible to be a SWE for those who still dig programming at our age. But you have to play by the rules. That being said, I don't think I'll last in such a position until retirement.
I spend everyday “programming” doing the same type of work I did before joining - mostly back end APIs, ETL, occasional front end work if I have to etc.
I just knew I wouldn’t enjoy being a small part of a large team coming from small companies where I could work up and down the life cycle from pre-sales, to requirement gathering, to implementation, to DevOps [sic], UAT and training.
I’m still part of a huge organization in the grand scheme of things. But my projects range from me the sole tech person doing everything to my working with a team where I lead or implement one “work stream” depending on the size of the project.
I think the point may be that, yes still as capable etc., but also with a ton more life-cycle experience in real-world development. So for someone hiring that values that experience, maybe they ask a bit more about that, and do less whiteboard work to validate that you really did go to CS school.
With a string resume, a hiring manager might think "They probably know what a binary tree is because it they didn't, they would not have made it this far."
Actually, three jobs ago back in 2015, I had two interviews. The first hiring manager asked me to do a merge sort on the whiteboard. The second company’s new director told me what problems he was having and that they were on an acquisition spree and what their plans were. He asked me how I would go about helping them.
Both interviews were about half a day, I got offers from both the company that asked me to do a merge sort paid slightly more. I accepted the second job.
Real business folks have real world problems to solve. They don’t care whether you can reverse a binary tree.
As an aside, one of the more junior people that I would be leading asked me how I would parse addresses while the director was in the room. I said I wouldn’t. I would license third party CASS software and explained all of the corner cases and then went into my speech about a company shouldn’t concentrate “on anything that doesn’t make the beer taste better”
> Real business folks have real world problems to solve. They don’t care whether you can reverse a binary tree.
I suppose it's all about the role you're applying for. There are "real business" where engineers are hired to solve technical challenges. Being able to solve simple algorithmic problems is a legitimate prerequisite for this type of role.
It’s not the role you are applying for. I’ve seen plenty of times where interviews were DS&A and the work was yet another line of business CRUD app. The job I turned down definitely was.
And let’s not pretend that all developers at BigTech are solving “hard problems”. I do have access to code for one of the major cloud providers.
I interview a lot of people and I ask all of them to write code (standard for our company). There's plenty of people that can talk about all sorts of stuff but can't code. Who do you hire to write software? Also do you want to work somewhere where software engineers can't write software? Do you want to work somewhere where the people doing the planning can't write software?
I keep hearing this like there are millions of experience developers that have spent an entire career fooling company after company without being able to code well enough to do your typical line of business CRUD app and let’s not fool ourselves. That’s all most of the 2.7 million developers are doing as far as coding.
I’m not saying the jobs are simple just that the complexity is figuring out what to write, how to organize it, how to deploy it, etc.
And before the gatekeeping starts, I programmed in assembly on four processors as a hobby by the time I graduated in 1996 and my third job around 2007 was to maintain a complete proprietary tool chain (compiler, VM (language VM), IDE) for Windows mobile. I spent my first decade plus out of college bit twiddling in C.
We do a lot of stuff that's not one line CRUD. I've no interest in people that can only do that. And let's not fool ourselves, even in orgs where they do the most vanilla stick blocks together software work there's a few people that do most of the work and lots of others that do very little. The other part of this is that there aren't that many good people looking for a job, most of them have one most of the time and when they switch it's usually through their network of connections.
You're obviously the kind of person I'd want to hire ;) Why would you mind writing some code in an interview? I don't ask anything that requires memorizing your data structures and algorithms textbook. All I'm looking for is people that can "think in code" which in the population of job seekers isn't as common as you'd think.
Don’t get me wrong. Back when I was C bit twiddling from 1999-2008, we had nothing but a compiler and no libraries besides the ones we wrote since our code had to compile across x86 PCs and a couple of mainframes. I had to implement most of the data structures myself.
I’ve had one coding interview in 25 years between 8 jobs. That one was in 2012. They had a Visual Studio IDE with skeleton code abs failing unit test and I had to make the unit tests pass as a pair programming exercise. I thought that was a very practical type of coding interview that I copied when I had to filter a bunch of contractors when I was a dev lead.
But now, if I leave my job at BigTech as a “cloud architect specializing in application modernization” - basically enterprise app dev/DevOps [sic], training, etc., before I retire, it will be at some startup looking for a more strategic role, even though I would be hands on.
It’s automatically a red flag about the job that I prefer if I’m not being asked about strategy and given a coding interview.
We do both but writing some code is a requirement. After you do that we talk (with the more senior people) about their approaches to solving bigger problems.
Big part of why programming is front loaded is that it's an incredibly new field. The entire field hasn't existed for more than 70 years. And that was if you count "Niche academic field that a few dozen mathematicians knew about" as the start.
It didn't become like a job job until what, the mid 1960's? That's 60 years ago.
And the number of programmers is doubling every ~5 years. Of course it's front-loaded with young people! The people who have been doing this for the field's entire time of mass popularity (1980's onwards imo) haven't even had time to get proper old yet.
But also: The more experienced you are, the more your biggest value isn't in banging keys on the keyboard. A company would much rather leverage your thoughts and opinions and that may look a lot more like technical leadership than programming. Even though it's still engineering.
Hmmm as a 53 year old programmer I've had the exact opposite experience. Because of the large diversity of my skills I have more offers for work than ever before.
Not the person you are replying to. But I did it by focusing on learning soft skills and project management skills - even though I am not a project manager.
I focused on small companies before my current job where the director/CTO was looking for people who could demonstrate a history of being “smart and get things done”.
I avoided the leetCode grind by preparing for a couple of years to target the cloud consulting department of the two of the major cloud providers or if necessary one of their partners. I knew that a combination of software development, infrastructure, cloud, and soft skills would give me a competitive advantage.
I studied my ass off! I did 300 LC questions and could finish LC mediums pretty easily and I found that most companies concentrated on easy and medium.
So honest question. I presume you spent months on those LC questions.
Do you feel that they were beneficial in terms of making you a better developer, or did you simply learn a bunch of solutions to puzzles that have no bearing on real world development?
You’re the odd one out, perhaps due to your own abilities and other special qualities. For the average programmer ageism applies though. And the largest majority of devs is in the average region
I think it depends on your adaptability.
I know few devs over 50, but the ones I do are like the dev you reply to - they are some of the most adaptable, T shaped skills. Deep domain knowledge & experience in a couple areas and broad experience in many techs.
Another factor to consider is post-peak-comp. You may find yourself in roles when you are older that pay less than they used to. This may very well be fine because you no longer have a down payment or kids college to save for, and if you didn't keep upgrading homes.. your mortgage payments 10-20 years into owning should a smaller and smaller percent of your income. If you are no longer chasing comp, you have a broader selection of roles and can be more selective.
That just isn't true in my case. I started my career in the late 90s and was the young kid at the office. So on my network is full of older developers.
Very few of them have been pushed out of the field. Yes many moved up, but the majority still code. The ones who had not moved into management are either retired (Over 65), retired early (Rich, big payday) or dead.
> For the average programmer ageism applies though
It's easy to blame ageism, and ageism is real. There are a lot of people who really resent older people and believe flat-out untrue myths about cognition, value of experience and work ethic. That said, every time a friend shares a beer with me and tells me the woes of trying to get a job when older, I hear this:
I can't get a job that pays me like I'm senior, but requires the skills of someone half my age.
The solution is to break out of that box, and either be ok with lower pay, or go for jobs that leverage the value of your experience.
> perhaps due to your own abilities and other special qualities
I'm sure if you looked at yourself, or maybe had someone look with you, that you'd find you have quite a bit to offer when it comes to ability, and especially special qualities. As you get older it's hard to understand what is special because you've seen a lot, and it all seems average.
So the question becomes “why would a 50 year old be an average programmer?”
I am very much the “average programmer”, but I learned a long time ago how to focus on “adding business value”, talking to customers (internal and external), writing, presenting, explaining concepts to non-technical people and even once a decade ago talking to investors and potential acquirers when a startup I was working for when they wanted to talk to the “technical folks”
I keep hearing about ageism, but never encountered it. At 54, I've just landed my last job a year or two ago and age wasn't an issue. As in all things tech, I think if you have the skills that are in demand, good jobs are not too hard to find.
> Because of the large diversity of my skills I have more offers for work than ever before.
"offers for work" or "job offers"? "Traditional" w2 full time go-through-an-hr-dept organizations possibly have more of an ageist issue than other scenarios. Freelance/consulting seems to still offer more flexibility on the age front, but it's more of a gut sense from speaking with those in my network.
I find the “I won’t take less than $X or else I’ll stay unemployed” to be kind of weird as a career planning strategy. If there is an under-supply of senior talent, everyone accepts and expects that the clearing salary for those roles will go up. Yet, if there’s an over-supply, many people seem unable to extrapolate from the previous.
Many hiring teams will look at an experienced person as “too experienced” and won’t even offer the job to an otherwise good candidate. They justify it by saying things like “this position is too junior for them and they’ll just leave when they get bored/find a better position”, etc.
That’s another apparent sub-optimization. “We’ve been looking for a while and we’d rather keep looking than make a level-Y offer to this good candidate.”
If the candidate says “I’m only taking this to avoid starving but will quit as soon as I find any other job”, then sure, don’t make the offer. If they don’t give any signs either way, assume they’ll stay for 18-48 months as is common and decide accordingly.
I'm better now than I ever have been. I was trash in my Jr years. Being discriminated against due to age would be a grievous error on the part of any potential employer.
I agree with you, but imagine being a discriminatory, but rational asshole.
Of course you're not going to hire a woman if you could hire a man - they might get pregnant and be away from work for a long time.
Of course you're not going hire an older employee that knows their worth over a recent graduate that isn't familiar with the salary they should earn. You can rip them off much more easily.
People can be cunts but still act with some rational motivation. That's why we have protected categories, to make sure that that isn't a strategy worth pursuing.
A lot of software companies don't care about having good programmers, they want people to do their bidding and be as cheap as possible. Younger people are nicer to look at too.
Such an important point. At so many places, effectively producing good software is low down on the priority list. In which case, a lot of the "rational actor" analysis around hiring totally misses the point.
Is this ageism implied for SV and like companies, or all of them in general (implied US-based anyway)?
I can't speak in either instance at this time, but I'd like to think ageism isn't nearly as widespread as it seems when discussed on here when it comes to technology-based work. E.g., Small town in Nebraska with one or two software houses versus SF.
51 grey beard here. Let me complain about the younguns. So much of what's out there today is, or is based on "solutions" created to solve problems that don't really exist. Rather than try to understand something so many engineers created "frameworks" to implement what was already there. Like 90% of current web stacks are just that. But new engineers are trained on that stuff and think it's the only way. That frustrates the hell out of me.
I share this frustration, but I think the root cause of the frustration is the difference between what I feel should be important, and what actually is important to people.
Getting great reliable software delivered quickly, which is easy to maintain and change, should be the goal, I feel. But if that’s the case, why do people invent problems to find solutions to, why do people spend multiple days a week in Scrum meetings, etc.?
But looking at everyone involved and their actual incentives:
- For a consultant, the objective is to maximize the billable hours.
- For the employee, to get modern skills on their CV.
- For the junior programmer, there is a more level playing field with the seniors when tech is used that’s new and nobody knows, vs. tech the seniors know well and they don’t.
- For the manager or owner of a product company, they want less stress having to make decisions and as long as the product makes money who cares if the software could be delivered 50% or 70% faster?
The psychological aspect of consultants and even employees trying to play a game with billable hours aside, a lot of developers of all ages genuinely feel using frameworks to do the exact same thing one can achieve with far less hubbub is a good thing, and they have trouble defending it. It's a cargo cult by all standards.
Many of us are living this now. If it's not the chasing of new frameworks, it is old frameworks no longer being actively supported, or key features never being developed. Then it turns out something like vanilla HTML + JS can do the job just fine, but you need to update everything to vanilla to make it uniform.
I think the issue is the batteries included approach taken nowadays.
Many developers nowadays seem to expect to be able to just wire things together without actual writing much algorithmic code. And the solutions have catered to that.
Those of us that are older lament the idea of using frameworks to increase our productivity, but still being more than glorified middle-men.
Why reinvent the wheel? I’ve seen “architects” who didn’t think they needed Entity Framework and went about solving the same problems (mostly around change tracking) very badly. Give me a widely supported framework any day over a badly written unsupported in house solution.
Sometime frameworks are a real help, sometime using it is just making thing bloated and it's hard-linking the future to someone who have the knowledge of the framework.
I would much rather “hard link” the future to a publicly available documented framework than one that a single person who thought their problem was a special snowflake wrote.
Which is why I've been paid good money to both maintain and bring up to speed old RoR applications that were so out of date you had to manually patch the C libraries just to get it working.
This attitude is common, that these frameworks are not, themselves, dependencies to be managed and protected from.
In medium and large organizations, manager pay and influence is mostly related to the number of employees managed and the size of their budget. Managers maximizing these two variables explains a lot of behavior that seems unreasonable to employees.
As a consultant, I try to reduce my billable hours as much as possible, then charge an appropriate amount for the value I have created, not the time spent, and this leaves me more time for more clients or leisure.
I can't speak to the prevalence of this mentality, but it rings true for my consultancy. The idea of maximizing hours is absurd. We do everything we can to minimize hours, thus maximizing value to the client. That's how we keep our clients happy, and make room for more business.
I sort of know what you are saying. Being dealing with so-called "server-side rendering" v.s. "static generated" recently, and these feel old / boring. It has been 15 years and mostly the same thing reinvented.
However, it is not a negatively thing. We may be able to setup IIS / Apache with Squid two decades ago to do similar things. The bar to do it now is much lower, and the tooling to help achieve that is much better overall (there are some not-so-great: Figma is a great design tool, but it doesn't translate to code directly unlike Dreamweaver / Borland VCL / Visual Basic, but I heard Framer is doing good on that front). That is part of the reason why there are so much more participation of labor in this industry: it is more graphical and easier to do (even terminal tools, largely do the similar things, are much more graphical nowadays!).
My company has a tech stack consisting of all the latest and greatest devops/tooling/cloud services, and an old timer like me wonders if that could have been just implemented as one C++ binary running somewhere.
Seeing all the JavaScript kiddies rediscover the speed and UX benefits of not using massive front-end JavaScript libraries to display simple web pages in the last few months has been alternatively hilarious and frustrating to me.
I feel it never really was about denying how effective plain web pages are but rather that faced with the choice of a wonderful DX with just JS, and a more difficult day to day with a mix of both, we picked the first. Sometimes at the expense of the end user, yaddi yaddi yadda, etc.
Good solutions for the "have your cake and eat it" scenario with exceptionally good DX are just now reaching some maturity.
There’s a legit issue in there, but us old’ns might have to own up to some of the problems we’ve caused (or even just failed to solve) and the legacy we’re leaving. ;) I’m mostly joking, but I honestly don’t think this is a young vs old issue, I think it’s a byproduct of happening to live through the time when the internet took over the earth right while programming exploded as a career. The amount of choice, complexity, scale, and expectation in software today is so much higher than it was 20 years ago.
Putting together a decent web app today that is competitive with what’s out there and doing it in a reasonable amount of time is something that just requires frameworks and library mashing. Even though I can fully empathize with your comment, from experience, and even though my beard is almost as grey, piling stuff I don’t understand together from yarn or npm is exactly how I start a new web app. My job recently switched from web to hardware, and the workflow changed dramatically into writing and scrutinizing every line of code, and complied instruction even. But even still in the hardware company there is an overwhelming sea of choice and complexity and an army of young and old programmers all borrowing and reusing code at all times, with everyone just treading water and understanding only the tiniest sliver of it all.
I think we have no choice but to embrace the fact that it’s no longer possible to avoid swimming in 90% code you can’t control or understand, and figure out how to better manage it and encourage people to snorkel under the surface whenever they can. I don’t think we should blame it on the kids though, they’re just trying to get by the same way we did, but in a different world than we had. The good ones will still shine through and be amazing, and the rest can learn their mistakes the long way just like we did when we were young and obstinate.
I definitely had some fears about it, and there are things I miss about web, but it was easier than I expected. I was reasonably prepared though, and it wasn’t as big a jump as my comment above might have made it sound, since I was doing C++ and video game programming before doing web dev, and my hardware job is centered around graphics and is still mostly software work.
If you're talking about web applications then I tend to disagree. The SaaS paradigm and the UI living in a browser are relatively new ideas that are still maturing. I don't think there is a lot of good "what was already there" and we're just seeing the evolution of tooling for this ecosystem, not completely decoupled from the evolution of the large companies that rely on this tooling. Not sure it's worth getting frustrated about... I tend to just stay away from it because I prefer to work in areas that are less fluid. And sure, sometimes there's just Not Invented Here syndrome and let's reinvent the wheel instead of using existing wheels. Nothing new about that either, it's always been like that.
All that said, the principles of how everything works are unchanged. People that only learn to use a framework are just not good software developers. People that understand the principles can work in any framework. This has always been true and is still true. There's a shortage of people that really know their sh*t and there's always been as well. That's great... I'll never run out of work (I might run out of motivation ;) ).
I once had an experience where I asked a younger developer why they didn't use cookies for a solution they were using JWT's for. Their answer? They didn't know how to use cookies.
I was bemused, their solution worked just fine, it's just all the extra infra needed when compared to cookies, which would have solved the problem just fine.
I'm in my mid-40's and I would apply that observation to scrum (and software dev in general). What I tend to see are a lot of very earnest people who are legitimately trying and the behaviors often associated with scrum are what they've been taught works.
Truly understanding what goes into successful software dev takes years of work and is more craft than algorithm, so I can understand the challenges.
The only thing I hate more than the ckusterfuck of the modern front end ecosystem is coming behind an “Architect” who doesn’t think they need them and reinventing the wheel badly.
I learned how to code when I was twelve. I wouldn't have if I didn't in some degree enjoy the actual act of coding, the moment to moment typing on the keyboard, composing algorithms, designing data structures and logical flows. But in the back of my mind I also always regarded coding as a means to an end. Sure I became engaged in language design battles, API design philosophy, but the magic with computers was always, for me, that you could create something from nothing, this totally metaphysical creativity, really. To some extent I see this passion transgressing to other spheres, such as management, communication, planning across departments, office politics. As an adult, I don't play video games, and artistic pursuits and ideals have also become more abstract, the particularities more sedimented, incorporated in the grand scheme of Life. On top of that, the fact is that most programming jobs are glorified plumbing. I'm reconciling with the fact that the romantic days of hacking are perhaps a thing of my passed. I don't really listen to music the way I did as a teenager, so I can't expect programming to remain the same either.
The magic, curiosity and joy I had also faded for me once. Like you say, much of my jobs included lots of plumbing. For work the elegant solutions that gave me joy would be seen as anti-patterns. The languages I enjoy would scuffed at as being relics. The problems I enjoy seen as useless because there are already solved in bloated over complex enterprise libraries.
When I would program for myself in the weekend I wanted to work on problems that would look good on my CV. Focus on techniques and languages that will be beneficial for my carrier. Soon also my hobby coding became a lot less enjoyable.
I then decided to seperate my hobby and carrier. In my spare time I started working on the things that fascinated me. Implementing operating systems, creating software rendered 3d engines, compilers etc. All from scratch. All in my favorite language (which is Common Lisp for me). Not caring if it would bring me money once, not worrying if anybody would use it or wanting to put it on my CV once. The only reason that is to enjoy it.
Straight away the magic I felt as a kid about computers came back in full strength. It hasn't faded since. And the funny thing... I started enjoying my enterprisy work also again. Already getting my coding passion fix in another way I could appreciate my work and the way of working for what it is.
This is why I'm starring to get interested in games programming. It is so far removed from the kind of code I do for a living that it is a lot of fun and recaptured the magic of learning to code when I was 11ish.
Same here (separate hobby from career). I needed to let myself re-discover the things that made it magical, switch from resume-building as my goal, to "what would be fun for me to do now?".
I have a similar background, but still find programming very rewarding.
Not at my day job, that is and has always been a series of mundane chores. I sadly think expecting to get paid for stimulating programming is fairly unrealistic. There is just not a lot of market for solving interesting problems or designing well-optimized code.
I find other avenues to build interesting things instead. At 35, I'm able to build things that I could never have when I was 15 or 20 or 25. I have so much more experience with what works, I'm much better at identifying which decisions matter, and which corners can be cut.
Doing interesting programming work is not unrealistic, but you need to make it a priority if you care for your day job. 3D graphics, robotics, physics simulation and AI/deep learning are still exciting to me after decades.
I learned to code at 12 in 1986 in 65C02 assembly language. By the time I graduated from college in 1996, I had done hobby programming in assembly in four processors. I didn’t do a single side project from 1996 to present unless it was just to learn a new to me technology for my next job.
During that time, I was a part time fitness instructor as a hobby, I trained for half marathons with friends, dabbled in real estate until around 2009 (guess how that worked out), got remarried, raised two (step) sons and now my wife and I are making plans to live a digital nomad life flying across the US. Our free time will be spent sightseeing and learning Spanish well enough to have a different experience when we stay in Mexico for a few weeks later this year.
I wonder where the genesis is of this idea that programming is young person's game akin to physical sports where speed, explosiveness and endurance matter.
It seems to me that it's an intellectual activity where one should go on for very long honing their skills and becoming better and better at it with age.
Maybe the industry sidelines the older more experienced technical folks at a cost, and that's why there seems to be a reinvention of the wheel several times in the software industry.
I'm curious if there are other technical fields that are similar to programming with regards to ageism.
Wishful thinking maybe, but open-source may help in this regard. As more and more of software is being added to the commons, those who've been there and done that can have a greater influence in driving progress.
Chess is a primarily mental competition, but players at the top of the world tend to hit their peak at around 35 years old. Players can continue playing at an exceptionally high level until the end of their life, but on average there is a gradual downward slide from that peak. Magnus Carlsen, the current world champ and arguably strongest player of all time, has decided to simply stop defending his title (held since 2013) at the age of 31.
I think something that tech and chess may have in common as well is the ever-shifting grounds. Electrical engineering of today is not dramatically different than electrical engineering of yesterday. But programming (depending on the domain) is quite different today than yesterday. This is going to result in an age bias because at some point you start to simply become jaded learning 'Incremental, overhyped, and not strictly necessary new trendy framework/language [that nobody will be using in 10 years] #2,743.'
The reason Magnus is not defending his title has nothing to do with some decline in ability. Last game versus Nepomniachtchi he won quite convincingly 7.5 to 3.5.
>“I feel I don’t have a lot to gain, I don’t particularly like [the championship matches], and although I’m sure a match would be interesting for historical reasons and all of that, I don’t have any inclination to play and I will simply not play the match,” he said on his sponsor’s podcast. [https://www.npr.org/2022/07/20/1112479750/magnus-carlsen-wor...]
For a man that loves winning and competing as much as Magnus I find it difficult to imagine he wouldn't be playing if he felt himself a significant favorite. His last opponent is a character with a well deserved reputation for implosion. He was playing no less worse than Magnus for 6 games, in a 12 game match. He then lost a single hard fought game and did his thing, blowing up and losing 3 of the next 5 games with abysmal (by his standards) play. That could happen again, but I think it unlikely and I'd say Magnus does as well. Nepo seems to have improved his mental game, and has been in great form as well - having just dominated a very strong field in the candidates with the highest score in modern times.
Carlsen is very strong, but his title defenses have never really reflected that - ironically with the most recent exception. In the two defenses prior, he only managed to draw the classical section and relied on tiebreaks. His defeat is all but inevitable, and I think he wanted to go out undefeated. I think the one opponent he was hoping to be able to play against was Alireza Firouzja. Alireza is young and will probably become a world champion contender at some point. But Magnus would have been able to count on Alireza collapsing under the unique pressures of a world championship match and let Magnus then go out on top having undefeated having defeated champions from 3 generations. Instead Alireza collapsed at the candidates, scoring less than 50% in spite of being the (at the time) 2nd highest rated player in the world.
I don't think programming today is that different. I've been programming since 1982 or so and I don't think it's fundamentally that different. You have to keep learning new stuff. That's the way it's always been. That's what it means to be a programmer. But the new stuff is just the old stuff and the basics are the same.
By the way, electric engineering of today is also quite different from electric engineering of the 80's. You have to learn new tools. Maybe if you work for an electric utility it's still the same though I tend to doubt that as well.
Keep in mind that we've seen an interesting phenomenon over the past few decades where the average peak age of professional players has been going up. This includes physical sports like baseball, football as well as things like chess, fighting games and various esports.
I think the peak age thing ends up being less due to actual aging and more due to the responsibilities of life taking time away from practice.
Chess is not programming. We have software that can beat any human chess player. We don’t have software that can beat even a mediocre software developer.
These sort of comparisons are rarely meaningful, of the way you seek to imply: We have software that can beat any human at calculating partial differential equations. We don't have software that can beat even a mediocre cat-picture-identifier at identifying cats.
Not only that but the younger are more maleable and gullible in some aspects but also have the better capacity (and willingness) to adapt to the tower of babel du jour.
Is it the hiring manager's objective to hire easily controllable apes that can type, or human beings that can grasp the product and business goals, shape the culture, translate technical jargon into easily understandable concepts for the uninitiated and make the employer a shit load of money by architecting and programming their vision?
Young people aren’t apes who can type, they’re bright young people whose inexperience lends them the qualities I mentioned in my previous comment. In many cases they perform quite well (but not efficiently IMO)
I"m not sure that the common idea is that younger programmers are more skilled, but rather that they are more in demand. Could be for a variety of reasons, for example:
- cheaper
- less jaded
- easier to "manage"
- more willing to do the boring work that the older devs don't want to do
I think you're right. I also think that what tends to bore an experienced dev may be less likely to bore a junior dev, just because it's newer to them.
In my mind, young male have a lot of hormones that make them compete and it shows. There seems to be clear behavioral change in the average programmer as they age. Later in life (oftentimes with family), they do not have biological set-up to code 14 hours a day whole year as they did before.
Obviously, outcoding everybody else is sometimes considered as a value and other times it is not. Shrug.
I did, multiple times for extended periods, and it was insane, yeah. Games and movies. I prefer to not do that anymore, so in that sense I’m doing less work as I age and choose to avoid insane overtime in favor of maxing out at mild overtime. I think I’m coding better now though, more productive, partly by being more choosy, partly from more experience, partly from making more rational decisions when not low on sleep and exhausted from overwork and missing friends and family. It is sometimes a problem in the industry that you can’t tell how productive someone is by how much time they spend typing code.
For most of my career, I've been told (and I believed) that I would probably get forced out of a hands-on individual contributor role as I aged. During the late-2000's, I even had an early midlife crisis and earned a law degree, expecting that I would need to make a career change into IP or something. That hasn't been the case.
What I think people missed is the compounding effect. The supply and demand for computer programmers seems to double every decade (maybe the interval is even shorter). With each doubling, the older cohorts become a smaller and smaller share of the whole. People look around and think, "There aren't many older programmers here", and base predictions off that observation. However, the more accurate observation would be, "There have been A LOT of younger programmers added here!". I don't believe that it's actually a zero-sum game, though.
I don't know if this human resources cousin to Moore's Law will continue indefinitely, but it's certainly held up through my career. Even when it inevitably slows down, I think that just means you'll see the age cohorts balance out more over time.