Aging programmer | Hacker News Reader

Aging programmer

world.hey.com

596 pointsnomdep367 comments

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.

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).

https://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html

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"

[1]: https://whoisnnamdi.com/never-enough-developers/

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.

Also, programmers are paid better than most people and early retirement is often possible. A lot of programmers don’t need to work into their 60s.

In my own case, when I have enough money to retire it’s going to be hard to convince me to keep working.

I know quite a few engineers who simply no longer need to work ever again, and are working just for "funemployment".

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.

I would probably try to do that too, but one bad week or month, and I'd be done.

Funemployment is when you are not working though

I guess there’s both fUnemployment and Fun-employment

I've been playing... (I mean, I've been) working with computers for decades.

My basic philosophy is that I'd probably be sitting in front of the silly thing anyway. Might as well be paid for 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."

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.

Snide all you want about it, but the country club trend provided community and physical activity

I’m only in my 30s and starting to find the idea quite attractive.

That’s what I said.

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.

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

i think it should be like this: can code / do whatever is being hired for + understads what we're building? hire. doesn't do a good job? fire.

its actually based on personality + a convoluted code challenge that has no bearing on the actual job.

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.

> 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.

> The strongest signal back then was serious contribution to any open source projects (strangely today that almost seems to count against you)

Would you mind sharing why contribution to open source might have a negative impact for an interview?

People in several enterprises have told me having a visible open source profile would represent a cultural fit issue.

They...wouldn't be wrong.

"You're too independently motivated to work here."

Fizzbuzz as a predecessor to whiteboard DS/algo problems was different than my recollection, so I did some digging.

2007: this is when I first encountered fizzbuzz as an idea https://blog.codinghorror.com/why-cant-programmers-program/

2005 article linked from there: https://www.joelonsoftware.com/2005/01/27/news-58/

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.

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.

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.

> 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.

OK, fair 'nuff.

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.

[0] https://news.ycombinator.com/item?id=32921823

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 speak it without an accent

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.

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.

I started off, writing device control stuff.

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.

[0] https://littlegreenviper.com/miscellany/the-road-most-travel...

Thanks! It was well written. Makes sense, I came from Android development and UI/UX is really important to get right the first time.

>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.

[1] https://blog.pragmaticengineer.com/software-engineering-sala...

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 it takes years to get the advanced stuff down.

Obligatory ask, bullet list of "the advanced stuff", please?

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].

[0] https://littlegreenviper.com/series/swiftwater/

[1] https://www.objc.io/books/advanced-swift/

[2] https://flight.school/books/strings/

> 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 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.

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.

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.

You can't game the cncf k8s certs. It's also an interesting indicator to see what date it was awarded. As in yesterday or 3 years ago.

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'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.

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.

Once at an hackaton a computer science phd student ended up in my team.

He was unable to execute a .py file.

Why didn't you help your teammate?

A PhD doesn't mean that a person knows everything. It means they made progress in understanding in a narrow area. Might not have included Python.

He was beyond help. That was far from being the only issue.

That's judgemental. Collaboration couldn't have hurt.

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.

> this.

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.

what about open source github repos that i maintain etc.? i think that's more valuable that a code challenge

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.

I think "can this person even code" certs can be like a driving license, and last a long time. More specific skills yes should be renewed.

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.

This sounds like a well refined process. DM me ;)

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.

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.

It has worked for me so far in my 15 year career.

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 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.

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

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.

https://www.bls.gov/ooh/computer-and-information-technology/...

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’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.

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.

If you've done good work for a few decades, you have tons of former coworkers willing to hire you.

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.

Yes, they refer me to their corporate recruiter and what happens next is "sorry, that's how the process is, we can't change it" :-)

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.

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.

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

Interesting.. do you have pair programming sessions in your company ? to accelerate routine problem solving ?

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.

There is too much to learn out there

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.

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.

> 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."

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.

> 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.

> > 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.

I've met all kinds.

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.

Thank you for the kind words, and I totally agree with your perspective.

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.

> 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,

I prefer leading projects over leading people.

> 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.

I’m interested in hearing more about your Socratic approach to management. Could you elaborate on that a bit?

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?" :)

Not to presume what the OP meant but I understood it as: answering questions by asking questions. See: https://en.wikipedia.org/wiki/Socratic_method

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)

You sound fun to work with. More power to you.

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.

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.

> 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.

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.

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.

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).

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

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!

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.

> . I wrote some guides that were popular,

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!

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.

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.

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.

> "they person that can't let the smallest mistake go un-punished"

Did you mean 'the' instead of 'they'? Did you do this on porpoise?

Here’s something I think a lot of people don’t think on: 40 years old is mid-career.

If you expect to retire at 60 (likely 65 these days) and you start working at 20: 40 is smack dab in the middle of your career.

I think that notion gets lost when we talk about ageism in tech and then people talk about 40-somethings.

40s or 50s are still prime time for programmers, assuming he/she keeps learning and coding and designing.

but those are still of small group, it's like a normal distribution, I read somewhere age wise there are only about 1.5% that are above 50s.

Programmers doubled every 5 years for 20 years. That's at least part of the reason.

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.

A significant reason for that is that the field has kept growing for decades. Of course a lot less people started 20/30/40 years ago than do now.

Two things can be true. 40 is mid-career, and tech's ageism includes it: https://www.businessinsider.com/we-hire-old-people-ageism-te...

Limiting a software engineers career to less than 20 years is a pretty fucking idiotic thing to do.

Sure. Ageism, sexism, racism, etc, etc, etc, are all fucking idiotic. And yet surprisingly popular. So we have to deal with them.

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.

> not going hire an older employee that knows their worth over a recent graduate that isn't familiar with the salary they should earn

that's the real problem, self and situational-awareness.

Except if the more experienced engineer is actually worth more, the rational actor will pay them more.

> the rational actor

i like the points in this thread. perhaps aging is just a natural bad actor filter. options narrow as we wise up.

> So we have to deal with them

this is the one thing you said I disagree with, unless you mean dealing with it by eliminating it.

Yes. Although in practice a lot of what we have do to is mitigating it, as eliminating the roots of it is a decades-to-centuries problem.

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.

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.

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.

This is exactly what I've found. My employer relies on my experience and values my opinions as much as they value my actual code out put.

The same goes for EVERY profession.

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.

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 know several 50s something programmers who have plenty of work. This is in big-corp IT not the younger SV scene.

Only an asshole cares how old somebody is. Reminder also, ageism isn't just a bummer, it's illegal.

Most people aren't going to take legal action, but imo if you're discriminated against you have somewhat of an obligation to do so.

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.

Are there any studies on the phenomenon? I like reading peoples stories but at the same time I’d be interested in seeing the data

> 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.

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.

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.

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’m also in my 50s. My last job search got me 6 offers, from startups to FAANG. I’ve only accelerated my career as I’ve grown older.

How did you get thru the endemic leetcode stuff?

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.

Dang that's impressive determination.

I appreciate the response. Have avoided that so far on principle, but good to know that if push comes to shove there is a way to get hired again.

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?

> 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.

> Lots of companies only want young people

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.

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

I agree.

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.

> ageism in tech

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 think there’s value in trying to understand the thought process, instead of just throwing a label on it and walking away

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.

[0] https://www.scientificamerican.com/article/at-what-age-does-....

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.

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.

"likely 65 these days"

I think with software jobs paying what they do, retiring at 50 would be pretty easy.

If you start your career strong in your early to mid 20s and plan for it for then... yes.

Not all software engineers are paid ludicrous money though, and even in places that they are paid well the cost of living can be atrocious.

Things happen. But what I often tell people is that I'd probably be sitting in front of a computer anyway. Might as well get paid for it.

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 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!).

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.

My 2c as a JavaScript senior citizen --

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.

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.

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.

Is this not the typical mentality?

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.

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.

How was the switch from web to hardware/low level? Did u do some self studying to get a job?

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.

So true.

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.

54 no beard here ;)

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 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.

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.

> expecting to get paid for stimulating programming is fairly unrealistic

Works for me in ML.

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.

The cure to burnout - give yourself ample time to play and be inspired.

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 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.

Younger people with cognitive bias running the hiring shit show perhaps?

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)

> younger are more maleable and gullible in some aspects

> better capacity (and willingness) to adapt to the tower of babel du jour

this all sounds like you're describing people who can type and do what they are told.

and: we're all apes who can type.

edit: age is irrelevant. my point isn't that older people are better hires. hire for skill.

Weak managers hire weak subordinates.

Maybe because a 25 year old can work 12 hours a day, while a 40 year old often has family obligations that make that impossible.

Yeah but the very last thing you want is an inexperience person who types code 12 hours a day.

I don't think that many millennials want to work 12 hours a day...

Some millennials are 40 years old now.

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 never ever coded 14 hours a day except in competitive programming. Doing it at work would be insane.

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.

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

- more likely to be on call or work extra hours

- less likely to retire next year

>more willing to do the boring work that the older devs don't want to do

No body wants to do the boring work. I think more experienced devs realize that a boring assignment isn't personal, its just business.

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.

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.'

> Chess

Chess is not a good analogy. It is a singular context. The real advantages that being over 35 and programming brings are:

- You are able to juggle much larger and different contexts at the same time - You have immense foresight that enables you to architect larger things

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.

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.

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.

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.

> I have no idea about how effective pair programming is. My desire to discover it is zero. […] Related: working with people you can learn from is a wonderful source of motivation. […] My desire to discuss technical stuff with people, both to help and be helped, is at all-time highs.

FWIW pair programming is very hard to do well and usually pretty uncomfortable. It needs to be structured well and done in smaller doses with lots of breaks. But when it has worked right (which was a small minority of the time for me), it has been exhilarating for me, unquestionably much faster and more productive than coding by myself, and much more fun.

I do think pair programming is also a fabulous way to share workflow tips and tricks. Watching someone drive you will see things you didn’t know, and when people watch you they’ll discover your secrets. Even if pair programming is hard, I think it’s pretty good for the organization to have team members doing it on occasion to help propagate this kind of knowledge more quickly. But yeah YMMV and it does also require self control and letting people do things their way sometimes even if it seems slow.

Agreed on small doses, not full-time: I've done some pair programming with people I enjoyed working with, but only a few hours a week. It felt motivating and rewarding.

Absolutely, have even done it full-time. Most are justly scarred from bad experiences, but in the right environment with the right people, tech and culture, it's a total game-changer.

This was the only line I really disagreed with. Pair programming, when done right and with two engaged participants, can be extremely rewarding and speeds up time to develop/review/test/etc.

Either you're both at the same level, and you can feed off each other, thinking through edge cases and bugs as you go. Or you could be at different levels, where one engineer is teaching, and the other is learning. It's really a win-win in my opinion.

100% this. in my last job i transitioned into a role i didn't have much experience in, and i paired for a few months and learned more than i ever could have on my own.

the miserly "leave me alone and let me code by myself" people are siloing knowledge and probably not writing the best code or products than if their code could be critiqued in real time or on pull requests and so on.

a lot of adult software engineering is not in a vacuum but in a collaborative and fast-feedback based environment

Having done it very little, I'm no expert, but the situation I was in was that I was motivated but not knowledgeable, and I was paired with someone knowledgeable but wholly unmotivated. It let me be much more productive than otherwise, and put to use the other's experience without requiring them to find motivation.

Of course, if you're managing, and you know someone is not motivated, you probably don't turn to this as your solution, but I'm not management, so I could be wrong!

63 year-old career programmer here. I can attest that this list is pretty much a straight line to the place where I am at, with everything just dialed up a 20 year notch (hehe!)

I do want to add one more thing to the list:

* Find a well-managed team of really nice people that know more than you do.

Every part of this requirement is important, especially for generalists like me!

If you find this, life becomes lemonade.

40 years old is aging/old?! That was more than a decade ago for me and I definitely didn’t feel aged at the time. I still spend all my time as an individual contributor. Their have been efforts to move me into more senior/management roles and I have refused them all. I know my strengths and working with people isn’t one of them.

Was made a team lead recent and it's... interesting.

I always saw myself as an individual contributor, and rebel against the path that leads to what's effectively project management with zero daily coding. But being the lead of a smallish team, making sure everyone's working towards goals and helping more junior devs when they get stuck, is a surprisingly interesting challenge.

I graduated six months ago at 31 and am not starting my career as a junior at 32.

I started at 31. The beginning was somewhat rough as I had to endure a ton of pricks in their early 20s conducting interviews on their own.

Even to this day, I have never been hired after being interviewed by a youngster. I suspect karma might be a thing, so I just endure them all knowing little shits for 30-60 minutes and move on.

Donald Knuth was 40 years old when he published the first version of TeX.

We could make a long list like this. Enormous amounts of high-quality, game-changing software is written by coders in their 40s and 50s, often with a couple more decades of stewardship and expansion of their works.

Isn't unique to programming either. Loads of famous people produced something well known today in their later years. Many of which didn't start picking up the required skills before their late 20s, 30s, etc. Many works which in many ways, were far more difficult than programming is today.

It's primarily navigating social environments which makes software production so obscenely difficult. There's nothing inherently complex about most popular web apps once you have access to the frameworks used to make the tough parts easier. No amount of frameworks or technical knowledge is going to solve stakeholders with conflicting interests, or coworkers heavily in favor of slowing things down through unnecessary red tape.

> coworkers heavily in favor of slowing things down through unnecessary red tape

This happens a lot. I wonder what the root cause of this is.

I'm 60. I've been writing software since 1983.

For 25 years, in between, I was a manager. At one point, I progressed in my career, until I only managed, and did no coding (for money).

So I coded on the side. That's a big reason for all the open-source stuff that I have in my portfolio[0].

When I was told that the software industry has no use for old coders, I took my toys and went home. I was kind of butthurt.

But then, I've come to really, really like not having people interfering with my work, treating me with disrespect, and, worst of all, trashing my work.

So it's all good.

[0] https://github.com/ChrisMarshallNY#browse-away

I hope that ageism dies out. I'm in my mid twenties and I would like to start a business down the line and if I'm able to make it happen, I would like to help with this issue.

I previously worked at a startup where the head of the SWE department was in his 60s, and it was one of the best places I had ever worked at. The startup regularly employed older programmers and I learned so much from them and hearing the lore of when they were young was also fun.

Hey Chris,

I'm younger than you by a bit, have been coding since 1982. Some similar background (low level stuff, embedded, designed some boards). I'm now a manager (for a few years) and it's hard for me to find time to code which kind of maybe sucks. Am unsure ;) I still do a little. Given I have a family and other interests I just can't imagine myself writing software on my "free" time (which isn't that much given my day job is pretty demanding). That's what I used to do before this was work (high school and such). How did you manage to juggle work and do open source work at the same time? Do you just do this full time now?

Well, one of the reasons that this WFM, and YMMV, is that I’m, personally, a fairly OCD-type person. I’m a couple of fries short of a happy meal, so to speak.

Coding and architecture are my hobby, as well as my vocation. It’s a real pleasure for me to work on a software problem.

I have friends that own boats, travel, ride motorcycles, exercise, play golf, fish, hunt, take photographs, sculpture, paint art, cosplay, build drones, play music, build hot rods, etc.

I use that energy to write code. That’s also one reason that it has been so painful, having employers treat my work badly. I tend to take that stuff personally.

Also, I am a long-term member of an extracurricular volunteer organization, and this has given me a ready-made target demographic for my work. I don’t need to hunt around, looking for problems to solve. The downside, is that there’s no money to be made, Serving this demographic, and they can be a real high-maintenance crew. Rather demanding, and they tend not to play well with others.

I currently work on software more intensely, than I ever did, when I was getting paid. I’m probably devoting 4-12 hours per day, seven days a week, to it. I take breaks (naps, even), whenever I feel like it, and have a fairly full dance card, socially (see “extracurricular,” above). I don’t drink or use any “recreational” substances (not a teetotaler —I don’t really care what other people do), so I don’t have a lot of mental “down time.”

I have a family, and act as a bit of a caregiver, so working from home is important. I also no longer travel, all the time, like I used to. If I go anywhere, these days, it’s because I want to; not because I have to.

Like I said, I’m fully aware that many folks would not enjoy my lifestyle. That’s fine. I won’t judge others, for theirs, and appreciate it, when the favor is returned.

I am “the real deal,” though. My productivity is fairly high, but I have worked with folks that make me look like a lazy slob, and I’m no longer interested in playing ego games, or competing with others. I’m enthusiastic, open, friendly, and enjoy working in a team. I was a good manager, but hated it, and am glad to see the back of that.

I have been disappointed in the way that I’ve been treated by folks in today’s industry (I fairly quickly learned to avoid things like meetups), and, to be perfectly honest, there’s more than a little “screw you” in my energy.

But it WFM. YMMV.

Nearing 50 and am still coding. Been doing it for last 25 years and will hopefully continue till retirement.

I had a brief stint as a manager, ended up doing more coding than my team. That was the moment I decided to step back into coding again.

For me, coding is puzzle solving or playing with Lego. It is therapeutic. If someone can continue to pay me to play, why not!

I couldn't agree more with this post.

- Nope, I don't want spend my week doing 1:1 with a team.

- 40 years old and I was never so sharp as developer as now. Focused. Precise. Fearless.

- Being the most senior developer in my team, doesn't put me in any special position other than I deliver a lot of good code, I do a lot of devops tasks, i review a lot of PR and people hear me.

- I can scale my work through my peers.

- I trust and respect the managers and architects, because I understand how hard their job is.

- They trust and respect me because they know that I could do their work (and they mine) and the roles are not ranks, but choices.

I don't fear for my job. I know that in the worst case scenario, even earning 50% of my salary would be more than the average of the population and I would still have fun with that. I can work in a niche market like Java.. or hell even Cobol :)

I could earn probably double, maybe even triple my salary and then I read your comment and realized it's true. If my salary now were halved, it'd still be more than the average US income earner. I Googled "US population average salary" and they have a nice graph.

As a side note, get ready for the pitch forks, it started going up as we approached the then potential Trump era in 2016.

Yup, I could earn the double too, if i wanted to go back to office, be manager, or simply moving to Switzerland.. but as it is, is fine. We can be idealist and say: I work here because I like it, because I like the stack, because i like the product, etc.

btw in Germany, people are already sharping their pitch forks too..

“I have no idea about how effective pair programming is. My desire to discover it is zero.“

I stand with the OP. Maybe this is a young folks thing, but I don’t understand how anyone can pair program. It’s like going to the toilet with someone staring at you.

The idealized greybeard would consider effective pair programming as wasted time (there is no contribution by the pair).

And all other purposes (like training juniors) is not for immediate benefit.

I get collaborative work. But pair programming for me is a net negative: two people working together outputting less than one person working alone. I don’t even consider it beneficial in the longer term (training, as you put it) given the degraded performance.

The very act of programming is buiding a house of cards in your mind and turning it into code before (or while) it collapses due to our limited brain capacity. Keeping two brains synchronized in the process just seems… too much overhead.

Like the OP, I’m just not interested in finding out if I’m wrong or not. I don’t even want to give it the benefit of the doubt lest it takes hold despite being a bad idea, like many other bad ideas that we now have to live with.

Pair programming works for me in short bursts: when I'm stuck at some problem I would call a colleague, share my screen, and then live-code with me as the driver and him watching me and producing ideas. I find it very effective.

I think pair programming is almost always done wrong: it usually ends up being one person doing all the work and the other one watching.

I had a manager who loved coding at us. We’d get on a 3–5h zoom call and I’d watch him mumble and write code. It was exhaustingly boring. He called this pair programming.

So this is the (current) opening paragraph for my book:

############

There is a common refrain in large companies, almost a badge of honour.::

  "I used to write software, but then I became a manager and
  stopped. But I am still technical."

How many of these managers used to read and write English (or Spanish or Japanese) , and how many, once they became managers, stopped? But are still literate?

It is no longer possible to manage a company without reading and writing English (or Spanish or Japanese) But it is possible to do so without reading or writing code.

This book believes that it will soon be just as impossible to run a company without reading (and writing) code as it currently is to do so without English (or Spanish or Japanese).

All companies will be use software to gain what advantages in what military term "tempo of decision making contests"

This I call software literacy.

#############

The reason we old farts are upset is that there is an artificial divide between coding and the resource allocation and co-ordination of "management".

We need to focus on closing that gap - then coding is how we express most functions of "management".

Tbh I don’t understand how that gap could be closed. It’s not like this is the first generation or career or field with managers and ICs; has it ever closed?

It's politics - if we take a simple view of humanity over past 10,000 years we have seen a drift from "one strong man owns it all do as he says" to more distributed decision making - different resource allocation from different people - different concepts (trade, communication, cities, writing, money) have made it simpler / easier for more people to be invoked in the efficient allocation of resources

I think software is going to be a big part in this

Software already is a big part of this. The whole stack of any organization is plugged into software. From communication, to organization planning (jira?), to spreadsheets. What you call software literacy is already here, but it’s not code for management. Why would they work in code?

I would guess it’ll never be code. If code can handle advanced resource management, then at that point it’s probably AI and there will still be managers just dictating the parameters of how to manage.

I am amazed to think software literacy is here - I envisage the ability to use all the data sources, access the APIs - yet my own anecdata is most decisions trapped in spreadsheets, processes cutting across different apps and storage layers. It's still a mess.

And because it's such a mess, management is mostly about finding the "truth". If a reasonable version of truth were just there, how many people with managers as a title would we need?

Edit: I would also add that software writing is mostly limited to "coders" - most people in organisations don't have the training, and they don't have the access to the tools (permissions) and see above, why would they want it ! Literacy will be when the domain experts, can code as easily as they can write a report and do so to enhance their own needs.

It might be helpful to have a new term for what you describe. While literacy is a part of your vision, it’s not the most lacking part. As you alluded to before many in management know how to code, even up to the Gates and Zucks of the world, and yet here we are without them coding. What you’re dreaming of is the organization and accessibility of data/APIs. And even if you made everyone on earth software literate as you describe that in and of itself wouldn’t help the data accessibility problem.

So how can we get to a world where every decision a manager makes can be informed by an API? Hard to imagine.

Furthermore, I don’t quite agree that managements job can be reduced to truth finding. There’s just as much if not more trade-offs, values, accountability, human management (will there even be an API for 2 of my reports aren’t getting along?), etc. The world is complex and messy, too much so to be 100% defined in code.

I don’t see how this can be distilled into an API worth managements time without very strict schema and behavioral restrictions/enforcement or without AI that does the simplification and aggregation for you.

Also some tangentially related discussion here: https://news.ycombinator.com/item?id=32987094

As a 61 year old programmer, that knew this is what I would be doing since my first exposure as a junior in high school, I can say his insights aren't too bad. But 20 more years on, things start to hit harder. My best advice is to learn to coach, even if you aren't in a coaching role. Find that young 10x team member and teach them the subtleties of the abstractions that make a difference. Don't be offended when they rewrite your code to their way of thinking so long as it did not obfuscate the lesson, that's how they will learn.

Add 13 years, and I could have written this. I must admit I cringed a bit when the author said 40 was old. I still love what I do, and I have no desire to live the manager life of all day meetings.

If you can be the best NFL Quarterback at 45 I think you still have a shot at writing code at 40.

Which NFL Quarterback at 45 was coding at 40?

I’m approaching my 40s and I am not really worried. On the contrary I feel confident on my tasks. Author is cringe just like his masters at Basecamp.

>I never understood why some people despise the term full-stack.

More for the role: full-stack has you doing multiple roles, but is not compensated as such. You're even removing the communication overhead if the role had been split in two. It seems to me as a business move to compress roles and pay you less for double the capability in exchange for varied work. I don't think people should just accept lower comp just because they prefer varied work.

I don't agree about multiple roles, backend/frontend is just one way of splitting a system. It's not like you get twice as much done in a fullstack role, you just do half as much frontend and half as much backend (in an even split role).

But why do you think fullstack is paid less? Is this a generally accepted fact?

The reduction of the communication overhead is definitely non-trivial. Though many businesses don't seem to measure the internal performance of their systems when the programs are running on and between humans. So if it works to some vague, hand wavey degree, "fine".

By relying on the idea that back/front is "just" a way of splitting a system, one could say that SRE/Front is a way of splitting a system, or Sales/Support, or Finance/HR, and so on. We're of course talking about ways of splitting the system(s) involved.

I think the spirit of the original idea is that roles are defined by boundaries. The boundaries are definitely "made up" but they aren't arbitrary. The degree of expertise and volume of knowledge needed to operate effectively (or expertly) within a role, and the ease or difficulty of obtaining those requirements, should be acknowledged when a company describes a role they are hiring for. If the bulk of your roadmap is back-end work but you want to hire full-stack devs because its nice to have everything, this seems like sloppy practice (though totally accepted).

On the other hand there are plenty of full-stack jobs that really just mean "back-end but not going to throw a contract in our face when you have to drop into the browser debugger to solve a problem". This is the kind of full stack I am. I wouldn't be okay with being asked to work on our frontend for the next year but I'm perfectly comfortable with debugging, making recommendations, doing some front-end work if it means filling a gap when resources are constrained.

In my 20+ year career, I have met very few programmers who can actually justify the claim of being full-stack. Usually it means strong back-end that happens to have worked with some front-end framework fad, and less often vice versa. Specialists (UI/UX, database admins, CI/CD engineers, automation testers, just to name a few) are still very much needed and the trend to make everybody on the team “full-stack” doesn’t work well in practice unless everyone is a 10x developer.

I have worked on ASICs, FPGAs, compilers, routers, clusters, servers, websites and mobile apps. But I would not describe myself as a "full-stack developer". To me that implies a very specific thing - a RDBMS backend coupled to heavyweight javascript framework frontend.

May I steal this description of "full-stack developer": a RDBMS backend coupled to heavyweight javascript framework frontend

Fullstack never required a heavy frontend to my mind, simply reasonable js, css, and ux knowledge. Depends heavily on the product however.

So do you feel the same way about backend developers who use databases? Surely that's two roles: server developer and database developer?

Of course, they can't test their own code manually. That's two roles: developer and QA!

So a backend developer is at least 3 roles of work. Are you making 3x the salary you should be?

It's a commonly accepted view that backend developers know databases. Until it is fixed, there are two major realms now due to Google (Angular) and Microsoft (TypeScript), backend and frontend. I was once a full stack developer but refuse to touch Angular gargabe or TypeShit.

TBH you could add Architect and DevOps if they're doing architecture/writing IaC as well. These all can be individual roles. The formula doesn't necessarily have to be salary times roles, but it should be higher than specific roles like front-end, back-end, DBA, QA, architect which can all ask for high salaries on their own. In my experience, full stack jobs often have salaries on par with the specific roles which is my beef.

The biggest personal reason generalist roles should be priced higher is the time you spent to learn multiple things well enough to get a job doing them. If you accept a role as full stack that pays the same as a backend only role, you're essentially devaluing your own time. The other perks are reducing head count and giving the business that extra flexibility and convenience. If your salary doesn't reflect that, you're giving it away for free and we know how much businesses make us pay as consumers for convenience.

It might seems strange to consider a lot of factors, but you have to remember that generalists can bring quite a lot to the table.

I think the rush of boot camp grads all calling themselves full stack engineers after 3 months of working on a rails project really weakened it’s appeal. I used to call myself full stack as I genuinely can work across the stack, but I noticed it was a bad way to market myself. Now I just tailor my resume to the position much more specifically.

I don't speak for my company, but in my opinion they still get more value from me, net, as a non-manager than they would as a manager. I also think some of the most valuable work I do is not in the code I write or the systems I build myself, but rather in the guidance I can give junior developers on the things they build, and the way they approach their careers. If I get can someone in her 20's or 30's to adopt a useful technique or perspective it took me much longer to acquire, everyone wins. As Andy Jassy says, "there is no compression algorithm for experience". But there is opportunity to learn from someone else's uncompressed experience so that yours going forward is that much better.

Why would a programmer at any age be a good manager? Manager is a totally different job with unrelated skills.

Because people are more than just the skills they have that happen to apply to their current job function. And because management requires a skill set that -- like many others -- can be attained by someone who is willing to work to attain it.

I think of it in terms of leverage. If I knew for sure that my becoming a manager would let me be a force multiplier for my team, that they would all be enough better to more than compensate for losing me as an individual contributor, I would consider making the switch. Having been a developer myself, I would have insight into what gets in their way, and I could use my managerial powers For Good™ to get those things out of their way. At least that would be my intent. I've had excellent managers who had been good developers who chose this path.

Having said all that, one of my first managers early in my career was a high-functioning developer who was moved to a leadership role because that was the default expectation. He was a terrible manager; he played favorites and treated his responsibility as authority to be wielded against those he didn't like. I was fortunate that he liked me, but he stifled the early careers of some of my friends who were at least as good at the job as I was. So there is something to be said for not having developer-to-manager as a default expectation.

Recent research suggests no positive correlation between individual performance and manager performance in the same line of work. If a company insists on moving ICs to managers, even though this is irrational, the best thing they can do is retrain their lowest performing ICs into people management roles.

This post and its comments warm my soul. At 33 and a decade in, I’ve only recently started to worry about what the tech world in general is telling me:

That I have to become a manager. That I won’t always code until I retire. That I won’t be welcome in the workforce in my later years.

All of those things frighten me! I love programming, and I want to be doing it in my 60s, happily. Glad to see that people are.

Do not worry. Your every day startup may not (because their teenager culture), but the enterprises of the world love you. I am now crossing in my mid forties, being a paper dragon (architect) I still outperform the waste majority of developers in our groups. I have their respect and they have mine.

However, idle you never can be. Because being of age and not being able to run with the pack is bad. Luckily, it is not the framework of the day but more the soft skills which make the difference.

I'm 47 years old, I'm a staff data engineer, and the fire in me to solve problems through programming is as strong as ever, and I expect it to last until I retire. I have zero interest in managing people, but I enjoy working with colleagues and teams to solve complex problems (through as simple solutions as possible). I learn something new everyday, and my hunger for learning is insatiable.

Note: I get contacted by recruiters constantly, at least a few times a week. Yes ageism is a thing, but you if you're really good at what you do you're much more valuable than young engineers.

But you’re also more expensive and picky about where you work and what tools you’d use. That natural ignorance and inexpensiveness lends younger devs a competitive advantage

Fine craftsmen are very picky about their tools. Companies that rely mostly on hiring "natural ignorance" will have representative software stacks.

My 2 cents for people worried about growing old in tech - invest heavily in your network. Be nice to your colleagues, help out whenever you can. Yes, you "lose" 20-30 minutes a week but you possibly gain employment later on. All those colleagues will eventually leave to other companies and become a crucial part of your future employment. This pays dividends. Also being nice and helpful whenever you can is just a nicer life in general imo.

Forty? A mere child! I'm about to turn 59, and I spend my days coding. And I love it.

At my current job I could have easily moved into people management. But the modest salary bump just ain't worth headache as long they let me keep building software.

My plan is to ease into retirement over the next decade or so as an indie hacker. Maybe try to grow my current passive income side project. Maybe make new things or take on occasional contracts.

There are plenty of people who lose their passion building software or get tired of keeping up with tech. There's a reason for stereotype. But there are many of us who are living exceptions.

I keep seeing people lamenting something to the tune of "Hey I'm in my 40s, aren't I supposed to be expired? But I'm more relevant than ever."

The idea that you're expired at 40 gained hold in the 90s and 00s when programmers entrenched in 80's style apps had a hard time keeping up with the explosive internet takeover of software. Waterfall development of monolithic apps with synchronous I/O and multithreading didn't carry over well to SaaS. It's also kinda like how mainframe people had a hard time with the PC revolution before that.

But if you were building LAMP websites in 2000, that experience still carries over to today.

If some idea takes over again that requires a total rethinking, like maybe differentiable programming with AI-generated infrastructure, then there'll be a bunch of 40-50 year olds who'll find it too difficult to rebuild themselves around a radically different paradigm.

"I have no idea about how effective pair programming is. My desire to discover it is zero."

Sculptors, painters, writers are with you in this one...

It's very challenging to share creative space/material

Um... 40 year old calls himself "an aging programmer"?? Okay. I wasn't ready for that this morning. My first professional gig was in 1981, which means I've been programming professionally longer than he's been alive. And I wrote my first Lisp program in 1974. And yet I don't really feel that old.

It's sad that 40 is "aging". Programming isn't football for chrissake.

It's interesting that one can take away radically different things from a technical career.

For instance, at around the same age, I much prefer pair programming ; try to avoid remote work ; have little time for drawn-out technical discussions ; etc.

I wonder how much of these takeaways are career-path-dependent and how much are due to innate personality traits.

That is definitely personality based. Pair programming has an aspect of wasted time but it depends on the local culture.

The beauty of individuality. I’m of similar age and have learned a lot about myself as well. I would say quite orthogonal to both OP and you.

I'm over 60.

> Do people lose interest in programming as they age?

No.

> Is it accurate to expect that older programmers are slower,

I do think a lot more about code before writing it. I don't just starting typing in random crap hoping to feel my way towards a solution. Quick reflexes and high WPM typing is not useful for programming.

> make more mistakes,

Far, far fewer. In fact, one gets pretty good at zooming in on where the bug is in other peoples' code. It's a pattern recognition thing.

> and would rather be doing something else such as managing programmers?

No. Well, I would prefer to race cars.

I don’t see how the world will get by without experienced programmers staying in IC roles well into their retirement years. This is for two reasons.

First, the demand for software is going up significantly, and new programmers do not come with the advantage of experience, aka knowing what not to do. These newly minted programmers need mentors. They need examples. Businesses need adult supervision for these tasks which many managers do not understand.

Second, the demand for senior technical leadership is going to make it more financially rewarding to stay in a truly senior IC role. Going into management, product, etc. will not be as appealing an avenue to take your career to the next level.

I started in this field at 27, which was 38 years ago this past Summer. Do the math.

I still enjoy it most days, like always, there are days where nothing clicks, or as happens in the embedded field, the hardware just won't cooperate.

It has just been constant learning from day 1, and I think that, as much as anything, still keeps it fun. After 38 years, I still learn something new regularly. Perhaps because it I chose to work in embedded development that is even more true. New chips, new technology, it changes constantly.

Most of what I have done in my life, so far all in the field of communications, is already obsolete. T-carrier systems (E1/DS1/DS0)? SONET (Does anyone use SONET these days)? ATM (not the money machines...)? K56 modems? I guess some people still use DSL. IS95 cell service?

Constant change, constant learning. Yet the fundamentals at the bottom remain, so there is always this stable ground to stand on.

I have reached a point where I no longer want to lead, I no longer want to spend countless hours in meetings. I just want to have features to develop, technical problems to solve. And people younger than me to work with.

As you get older, always seek out organizations with people much younger than you. They are a joy to work with. And don't be grumpy, don't make assumptions, and don't insist on giving out 'advice' unless you are asked.

But do introduce them to the company 401k, and any employee stock plans. And do let them know about the concept of 'same day sales' on exercised shares. Their education will have given them a good technology jump start, but schools are still deficient on personal finance. Don't pry into their finances, but guide them toward good early saving behavior. Trust me, they will thank you five years down the road.

The big problems with aging in the industry are health-related. There are several occupational diseases that any programmer sooner or later will have to deal with and the older professionals rarely warn the youngsters about them, and rarely coach them with preemptive measures.

Deteriorating eyesight, lower and upper back problems, hemorrhoids, weight gain, carpal tunnel syndrome and other RSIs are very, very common in our profession.

If you're reading this (perhaps because you still want to be programming in your 40s, 50s, and even 70s), make sure to prioritize your physical and mental health above everything else while you're still young. That is way more important than learning how not to suck at interviews, recognizing algorithms and knowing data structures. More important than compilers, programming languages, tools, hardware and operating systems.

It doesn't help if you used to be an exceptional architect, but you can't physically sit and code for even two straight hours anymore.

There isn't a massive amount of old programmers, for the same reason why you don't ever see a 70-year-old roughneck. Yes, the work of a programmer may not be as physically demanding, yet it requires certain mental and physical shape nevertheless.

So, please, keep yourself in shape. And not only by studying and acquiring new skills. Stay healthy for as long as you can stretch it out. Because sooner or later, that all sitting, staring at screens and coding will make you sick. That's just guaranteed.

I’m just a little farther down the road then him and this list hit so close to home. Really the only major deviation for me is my intense love for pair programming. Over the years I have come to accept that there are people who just can’t thrive in that paradigm, for numerous reasons, but also many who can and when I pair up with one that can there is no question that we are producing well in excess of 200%. Further, it’s just a nicer way to spend 8 hours coding with natural guilt free breaks to go down rabbit holes together.

I am in a similar position oIf the author and I agree with most points

> I have no idea about how effective pair programming is. My desire to discover it is zero.

I used to think like that, but then, recently, I started doing pair programming with a colleague from time to time using vscode live sharing feature, and I find it amazing. Not really for the pure implementation work, but rather for the more architecture or design of things like API or data structures. I found that we are really productive spending about one hour or less together in the editor and brainstorming live the ideas.

> Communicating effectively is a complex skill that takes years to develop, and an essential one if you want to program professionally.

I suspect that a good chunk of the drive to send "aging" programmers into management is that they're much better at communication than their peers. And part of it has to be that a subordinate who is better at communication than the manager often becomes a de facto manager.

Leadership often doesn't respect organization charts. But this can cause a great deal of angst among anointed leaders.

I look back on 40 with fondness: I would have been 40 some time around the Y2K bubble. It sure as heck isn't old and I can;t see how a kid of 40 can write about ageing in the industry.

From where I sit, thinking about a 40 year old programmer in terms of "aging" is a good laugh. I started my career in the technology industry as a programmer at age 40 (not that I hadn't written code before that - I'd written quite a lot, but my primary gigs during that time had been in academic science, as a college administrator, and as a horticulturist).

I don't think there is any intrinsic reason one should age out of software development, if writing code is what you want to do. But many people do, particularly those for whom writing code is not an end, but a means to some bigger end. Although I wrote code, and was paid for it for many years, what interested me was not the code, but the problem we were solving with it. And eventually, if that's the case, you conclude that you can accomplish more - solve bigger problems, or make a bigger personal contribution to the ones your team or organization is working on, by coding less, or not at all, and architecting, designing, and directing more. And that's the path I took. Others may wish to, and certainly should be free to, keep right on coding.

But, and it's important - software development looks different from one decade to the next. Different languages, different architectures, different tools and evolving engineering paradigms. Whether you choose to remain a developer, or move into an adjacent management or design area, you will have to re-invent yourself to a significant degree, decade by decade, to remain relevant. Those that don't - well, they end up doing maintenance on aging systems with their aging skills, and not infrequently, wondering how and why their careers feel like a dead end.

I'm 62, and having a blast. Helped do some system bringup a few days ago that brought back memories of "lab time" in the 1980s, though we get firmware onto boards with tens-of-megabit downloads now, instead of burning (literally) half a dozen EPROMs for every attempt. Things have improved a little!

Firmware worked on the new board, the very first time. I consider that a career capper. :-)

I figure I'll go until I'm 70 or so. We'll see.

The idea that a programmer is “aging” at 40 is just nonsense that the tech industry made up to cut costs. Nobody would suggest that a 40 year old doctor or lawyer or civil engineer is “aging,” they’re widely acknowledged to be getting better until perhaps 50s or even early 60s. What might happen is that two decades of tech salaries make senior programmers not give much of a fuck anymore.

> My desire to manage people is at all-time lows.

Checks out. Last year, I retired from big tech at 40 because it just wasn't worth the headache. Now, I'm wandering, and it's fantastic. This is now the tenth month of just wandering, and I'm finding my footing with my SaaS which currently is in the red.

My only goal right now is to find partners which don't require me to compromise what I like doing (too much).

I'm approaching 40, and have so much more I want to learn. The only thing is I hope I keep my physical and mental strength going long enough. My plan for this right now is to keep physically active. Cycling to work (2x9km), and 2-3 weekly 5-15km runs.

Seems to work reasonably well, though I see I would do better if I increased the running even more, perhaps switching out some of those bike travels to running to work instead etc.

Aging. At 40. lol!

My the youngins have some pride. Not sure how to break it to you but, the web, phones, etc was created mostly by people 10 years older than you.

Aging, schmaging... 50 is a whippersnapper! I have had a long career in IT, starting (as a Cobol programmer in 1968 ie before the "aging programmer" was born!). Later I had my own systems consultancy, "retiring" some years ago. Never could leave the computer far behind and used Excel quite a bit but thought there should be a better way for some of these jobs. About 2 years ago, I started to learn Python, totally from the net and have written at least 150 scripts since then. At age 76, I have a new love (Python) and enjoy discovering new methods almost daily! THAT is an aging programmer! But it is keeping me young, I think...

> I used to be very sensitive to tone and manners in the working place. I still am.

Yup.

The old industry joke: "if your succeed... you will end up in marketing".

Senior staff tend to get better at spotting the standard industry cons, but I find it amazing people often think they are somehow going to outsmart company contract/IP lawyers. Legal encumbrances are often a necessary evil, but some of the agreements fresh grads eagerly sign read like a Faustian bargain.

One finds many people tend to disbelieve anyone that contradicts their personal biases, and some get indignant when told how the churn-rate for large firms will affect them personally. It is like wishful thinking bypasses years of statistics training, and basic numeracy. Many industries simply rely or a steady stream of gullible STEM kids to keep their Youth Employment Tax credits, externalize training costs, and provide stock bumps from a symbolic layoff for year-end investor reports.

I wish the Tech industry treated people better, but "it is what it is". =)

I’m a third generation programmer which is a bit of an odd thing, but a bit lovely. My brother is also a programmer. The bits in this About just just being “wired “ ring so true to me. There are things that to me seem biological as to how you view punch cards, fortan, whatever video games are made in, and JavaScript

> I have no idea about how effective pair programming is. My desire to discover it is zero.

> Similarly, I don't discuss the benefits of getting people in the same room to solve a problem, but I am not super interested either.

Admitting ignorance is a hallmark of maturity. Boast about it and the desire to not learn isn't.

I love this, and I can see myself agreeing already, while a few years younger it's quite reassuring to know I'm not just weird about some things.

One I have only recently come to appreciate though is paired programming.

> I have no idea about how effective pair programming is. My desire to discover it is zero.

There is a limit of course, but recently I've been doing more and more, not by instruction but just more sitting on a call sharing a screen and going through the work day. Good combination of chit-chat and some problem solving, it's actually really nice for remote work.

I don’t think I have it in me to become an old programmer.

I absolutely love programming. It’s the best feeling in the world.

A decade of doing it for money, being treated like an assembly line worker who gets bossed around by a PO that has no technical knowledge, and being constantly asked to drive the bus in the wall has sucked every last bit of enjoyment out of it. Or forcing me to go with a brain dead design that I’ve warned will cause us 10x the headache afterwards.

I’m not even 40 but can’t wait to retire and leave all these dumpster fires behind.

I feel like this guy could be me. As someone at about the same stage, almost every there here completely resonates. Except the "Aging" part, I expected he would be a 60+ year old programmer.

Didn’t know I needed a write up like this, but I did. I’m hitting 40 in February and naturally it’s causing me to… feel things. Lingering in the back of my mind since I started my career was a worry that someday I’d become too old for it.

It still hasn’t felt like that as I’ve aged but nevertheless the worry still lingers. It’s nice to see I’m not alone in these worries and maybe I’m worried for nothing.

AI will most likely be a far bigger threat to programmers than age in the coming decades

I've moved out of coding every day at work because I've gotten 'too senior' but my goal is to move jobs to get back into it and probably spend at least the next 5 years coding. What I do now is so high level that I can't see myself doing it for the next 25 years.

That will bring me close enough to 40. I don't really see me stopping coding then.

I don't get why you'd be too senior to code if you like it. And I was very surprised to see the article author calling himself an aging programmer already at 40. I'm fast approaching that age and I feel I'm more productive than ever.

At some point reading articles like this I was mildly worried about being employable as a programmer later in life. But not any longer. The amount of work seems to be ever increasing, and open positions get filled with middling talent at the face of persistent lack of skilled programmers. Seems like anyone with even a sprinkling of motivation and passion will not go without work for long.

> I don't get why you'd be too senior to code if you like it.

I don't get it either but at the company I am in.. everyone moves into positions where they code very little. It causes a lot of problems but that is how it is structured

We all benefit from a world where productive developers are applauded for choosing between parallel tracks as ICs and managers.

Productive developers don't necessarily make good managers. Been doing this stuff for a long time and never came across the acronym IC, what is it?

"Individual contributor", i.e., not a manager; a leaf on the org-tree.

I think more people would choose the IC path of there were more authority and autonomy in it.

I’ve gone the management route because I like making larger product decisions (or at least being involved in them). ICs at any level rarely get that level kind of input.

I low key blame the onslaught of product management for software as the problem. It’s pulled all the fun product stuff out of engineers hands. :(

Challenge yourself, learn new stuff, not how to make your 500th ERP in rust instead of Java, but program 3D applications, Virtual Instruments, or move to hardware, embedded programming, IOT,...

As demonstrated by Adobe's Figma acquisition, there is plenty of opportunities in the authoring/graphic tools. So maybe you'll make the next Figma.

> Back in college, they told me that I would start my career writing code, but eventually, I would move to a position where I would ask others to code my designs.

Without continued exponential expansion of the industry, seems numerically impossible that everyone would eventually become a manager or architect.

I started my career as a full stack and I've been doing it so far well.

I like to design and think thoroughly about business logic and data layout and also how you host and architect the final running services/websites.

It seems that I just can't leave the software secret sauce being secret.

I’d be really interested to see what the experiences are of developers who started at 40+.

If you start at 40+, you are used to the most recent tech: you are more likely to use Python or Go than Java or C++. You’re going to be “cloud native”.

Does that help or hurt?

Sad reading. Meanwhile anyone with a title above of the middle manager is collecting big moneys and asking for an 'update'. I would take a management role any second, no need to explain how bad it could be.

The only factor that matters is whether you can keep learning.

Developers that "age out" (author is only 40, lol) are those that think they can just stick with the same technology forever. Not in this industry.

Everything you're describing would be ideal for management, but creating ideal outcomes and utility isn't the point of why we work in the US.

Fourty year old programmer aging! Give me a break!

As a mid-40s programmer, I can agree with most of these observations.

Looking at myself, I think my biggest strength is in knowing what not to do.

You're only 40? Hold my beer. I'm 68.

> I don't enjoy switching contexts. My perfect agenda is composed of a single meaty task I can focus on for days.

So large companies only?

I work for a large company, and I can say that context switching is also a problem here. I guess it comes down to the organization, or maybe the individual team. But yeah, there isn't a week that goes by where a development task isn't interrupted by something.

From my experience it's the opposite, the BS and distractions to work ratio in small companies has been far better and the small company also has huge chunks of work to do.

Aging? Dude, check back in in twenty-five years...

45 and that's basically me. In particular this:

"I have no idea about how effective pair programming is. My desire to discover it is zero."

Just turned 60.

One thing I've found (I started programming when I was 11) is that you can get better at judging situations/application/specifications and choosing NOT to write code in certain obvious ways or at all. Sometimes the right solution isn't the same old skill.

I've also come to realize that MOST hiring managers barely don't what they are doing as programmers or as managers. They have the authority of position but zero common sense or learned social skills to know what they are doing in their position - they are BEST IGNORED. Which can mean you won't get hired by them but often that is actually for the best - if you care about an idea, you should be the boss or be working with like-minded people who know what they are doing instead. That corporate job might just be 100% pure trash and a waste of time.

This last reality is why I do NOT value the idea of working for FAANG companies - there's nothing good about what they do or how they do it. They are generally evil in that sense. So why would anyone work for them? Mostly to make some money and because you don't know any better.

40. lol

Reply on news.ycombinator.com