Hacker News Reader

> There seem to be more articles about age popping up on HN lately. I find this both weird and disconcerting.

Not so weird.

We're now 30+ years from the dawn of the desktop PC marketplace. 20+ years from the dawn of the web and associated original internet startup mania. 10+ years from the post-collapse web 2.0 resurgence with Ajax and frameworks. Pushing a decade since the introduction of the smartphone.

Every bright-eyed twentysomething that could bask in the glory of their wunderkind youth at the start of each of those eras -- everybody who knew PG was talking to/about them in his essays -- has now wound the course that time dictates everybody's gotta take: they arrived at being older.

So of course there's a lot of interest in what that means in the software industry. And maybe some rueful reflection from some participants on what they thought that meant when they were younger.

"but overall what I gained translates into Getting Things Done. "

This. I don't pump ridiculous amounts of code, but what I do, Works, and is mostly bug free or easily repairable. Thus I have a reputation as a guy who gets things done.

Companies should really be aware of the maintenance overhead caused by fixing old badly done code.

Maybe it's the market dynamics. Most code bases are new (their age is not measured in decades) so the organizations have not gained the institutional understanding what a sinkhole of profits badly executed code is. Some companies use this as a business model an charge "maintenance costs" and such things so there is also the pathological motivation to maintain this status quo of "implement cheaply, fix expensively"

I have a developer friend in his 50s. He writes the most solid code I've ever seen. I'd be surprised if one of his services hits a major bug in production.

However, there's a slight problem: We don't need that level of solidity. The rest of the stack is comparatively less solid, so his time would be better spent getting ten easy, frequently-hit bugs out of the rest of the codebase, rather than get one unlikely-to-hit bug out of his.

He hates producing code that's not up to his standard, but when our fleet of cars consists of a Lamborghini he built and a beat-up Yugo some other guy built, I'd rather my friend changed the rusty oil of the Yugo rather than make sure that all the bolts on the Lamborghini are within tolerance.

I 100% agree with this: the lesson to be learned from getting older and being burned by bad code is not that no code should ever be written badly, but that you should learn how and when to care, and by how much. I think too many experienced programmers have been subject to problematic code that they pre-emptively try to make everything bug-free, and very often times that's a huge opportunity cost.

> Companies should really be aware of the maintenance overhead caused by fixing old badly done code.

This is a fascinating theory on programming ageism. It's common knowledge that most software buyers undervalue tech debt and the costs of maintenance/upgrades. That presumably translates for less interest in planning, experience, and thoroughness compared to speed.

And most of that isn't controversial, but I rarely see it raised in the context of preferring young and inexperienced devs. I suspect there's at least some truth to it, because highly self-aware software companies seem uncommonly willing to poach older experts.

I am under 30 but ageism scares the shit out of me.

I love to build things and I am not keen on sliding into a management position. But this becomes the easiest career path once your soft skills start to increase to the detriment of raw coding skills.

On the other hand I've seen enough engineers with decades of experience who said no to going into management and who are now basically irrelevant.

Both these outcomes are scary but they seem to be the defaults for someone who goes with the flow.

I just turned 50, and I still code and still love it. Like other people here have pointed out, keeping your skills up-to-date is key, and making a conscious decision to stay coding instead drifting into management.

A good way to stay relevant is to change jobs now and then (maybe every 5 years or so), and also using your own time to learn new things.

The problem with keeping your skills up-to-date is that many of the skills listed in laundry list job reqs are in things that have only existed for a few years. They're things that a sharp college kid can be just as knowledgeable about.

Yes, definitely possible, kudos for pulling it off! But it requires careful long-term proactive decisions and actions. Which is not what most humans are particularly good at. That's why I used the word "scary".

When you are a junior engineer you just crank out code and the level and employability of your skills automagically increase. But after some time this free lunch quietly stops. You suddenly have to manage your career.

Right. People should be less concerned with competing with people in their 20s and more concerned with how they are going to keep up with the other people their age who instead of doing fun, hacker, startup stuff and chasing money spent their time being the "stupidest" person in the room and learning the (an) industry.

"Sliding into management" might sound like it's an easy path, but it's an entirely different profession. Only those who are interested and have the ability should ever consider this route.

I think both things are true. Plenty of people do slide into management, but only the genuinely interested should.

But what are the alternatives?

You are absolutely correct: You should only go if you are interested. But if your alternative is to be jobless....

Recently turned 31 and I too am scared of it. I think all software engineers / devs should think about FI/RE (financial independence / early retirement).

Or at least get setup, so you have money in the bank. You never know when you might need it later on in life. If you do experience tough times, for finding a job.

Beyond getting things done, I read recently that older, experienced developers shape culture. It is really true, and I didn't realize it until recently. You have much more obligation when you are older to act in the way that you want your team to act and approve what you think should be approved. You are usually a mentor and role model whether you want to be and think you are or not, and you can't just work hard and that rub off on your team; you need to show them how to help themselves rather than do their work for them, otherwise you're setting yourself up for problems.

read recently that older, experienced developers shape culture

Do you really believe this is true? Do you think general industry culture reflects experience and maturity? No, it is the exact opposite!

The older developers on the team shape culture. So, when they are not very old themselves, you get what you get.

"... I do have less ability to do brilliant-late-night-ninja-coding stunts,..."

Isn't this an advantage as well? How many ninja stunts have you seen without hundreds of bugs and being easily integrated into existing stuff and not requiring to change many existing things because they don't fit anymore with the genius code (and thus replacing well tested bits with alpha quality code)?

Being older helps to plan well before you code and get a result that does the job. As you said: getting things done.

Even long ago, I discovered that once I reached a certain level of tiredness, it was pointless to keep coding, because after a night's sleep I'd realize it was all garbage and had to revert to a previous version.

Past that point there's no possible justification except "I need to show something functional to someone tomorrow".

I confess that, once upon a 5 A.M., I thought it would be clever to store X-Y position values not as a tuple but as two halves of a single int. There was a reason, but looking at it the next day there certainly wasn't a good enough reason. That set my low-water mark for coding while tired.

Yes, this. And that goes even if one is already awake due to insomnia: one owes it to oneself as well as to one's colleagues not to write code when one's mind is not in tip-top shape.

>How many ninja stunts have you seen without hundreds of bugs and being easily integrated into existing stuff and not requiring to change many existing things because they don't fit anymore with the genius code (and thus replacing well tested bits with alpha quality code)?

I am familiar with the stereotype you're referencing, and have seen it from myself and others. However, to genuinely answer your question of "how many ninja stunts have you seen without hundreds of bugs..." I must answer: Many.

For the first 3 years of my company's life, I a full half of the code was done as "late night ninja coding". In between getting steady work done, I would often think about a few harder problems/features/projects, and take notes from those thoughts over a few days/weeks,on what would be the best method of accomplishing said problem/feature/project. I called it the "think twice, code once" mentality.

Eventually it would culminate (almost always in the evening) when I would either realize one last detail that made it all click, or realize that there was nothing left to plan out, and it was time to dig in and code.

Cue an overnight session where all of that planning would be brought into reality. With tests.

Even now, when my lifestyle and product allows for less of this, I still do so occasionally and it brings me great joy, significant productivity and very few bugs. Think twice, code once, and of course YMMV.

Maybe that wasn't a comment on the practical benefit or otherwise of all-nighters, but on the perceived benefit from management.

If a manager doesn't think you will be up for a 36 hour shift, maybe they won't hire you.

Today, an interviewer put it to me this way:

> Why would we pay for someone with 10 years of generalist experience overall when we could hire someone with 5 years of experience in technology X.

They nominally claim to hire smart, generalist engineers.

Yes, some of us have been around long enough to know that implicit declaration of variables is a bad idea, not a brilliant one overlooked by everyone else :-)

This is pretty much how I feel these days. Short term memory is nowhere near as good, (a problem solved by pen and notepad to a degree). But far better skills around the bigger picture of writing an application.

Are all young developers he way you're describing?

I think I'm more similiar to what you describe about tourself than about young devs.

I count three typos in your post, I guess we are not that similar after all.

When I was 25 I also thought differently of myself. And I think when I reach 50, I'll look back and marvel at how silly I was at the age of 40 :-)

Probably :). Anyway writing from a phone in a hurry does cause typos.

Late night ninja stunts can still be done; you just might want more chemical assistance (stims) than before.

A bit off topic, but I love the share feature of partsbox. That's a killer idea. Well done.

Well, to be honest, sharing part databases is something I intend to do, but it isn't implemented yet.