Hacker News Reader

Comment by tharne | Hacker News Reader

In addition to ageism, I think the proliferation of the MBA/McKinsey school of thought really works against older programmers. You have an increasing number of managers who have little to no domain knowledge around 1) Programming, and 2) whatever industry they happen to be working in. What's worse, is that they see no problem with this because they think they "understand business".

What this leads to is a lot of dumb decisions. One example in this case is that, to someone who's never written a line of code, a 25 year-old developer is the same as a 50 year-old developer, but at half the cost and without the hassles of things like kids to take care of. You need to have a decent understanding of the work developers do, in order to understand the value the 50 year-old developer brings and why paying him or her 2 or 3x the 25 year-old is actually a bargain.

View on HN

> You have an increasing number of managers who have little to no domain knowledge

After seeing this time and time again, and because I was getting older, I made a conscious decision to move into management. Be the change you want to see in the world, right? Now my output is mostly spreadsheets and powerpoint, but I enable my team to do good work as I insulate them from the bullshit. I can always get down into the trenches or work on a side project if I need to scratch that creative itch.

Yes! It's probably just a demographics thing that will even itself out in the future. I mean: People like you will become managers and there are many programmers in the younger generations to draw candidates from.

Haha!

Cause nobody every changes, loses their edge or falls out of touch with their tech roots, right?

We just need to get these clueless dinosaurs out of power before the current woke kids take over!

I really respect that attitude.

I happen to be doing a security assessment on some products (PuTTY etc) at the firm (Fortune Global 100) where I am interning.

It baffled me to read a directive from management that said that we should shy away from open-source projects - I must confess that I was somewhat frustrated at the sheer ignorance in the memo but your comment allows me to see a silver-lining. I hope that one day I can rise up to management and make decisions based on greater nuance than simply saying "OSS bad and insecure".

I think the general aversion to OSS is more that there is no responsible actor. In many cases, if you integrate a third party paid solution you can file a bug on that solution with reasonable confidence it can be a priority. If you use code from another team at the company you know you can file bugs on them. If you write code yourself you have confidence in fixing it. There is a danger with integrating OSS that you have code in your stack that no one knows well enough to fix and no one is responsible for. If something breaks you might have to learn a sizeable amount of code and domain knowledge to make a fix. Filing bugs on OSS is not viewed in the same way as filing bugs on paid third party solutions as whether the bugs are a priority to an OSS solution seems more risky.

Note that large amounts of OSS is used in companies, but it's generally code that developers are expected to know well enough to dive into if need be. And code that is popular enough to be well tested for bugs and known that breaking errors in the framework will get fixes. Examples would be things like Python or Node.js.

As a manager a potential problem you can have is a major bug your team is responsible for that no one is qualified to fix and thus your only reasonable time estimate is unknown. Avoiding certain parts of OSS is often a precaution against this situation.

> I think the general aversion to OSS is more that there is no responsible actor.

I have filed many bug reports for paid software over the years. The bugs were fixed exactly 0% of the time. If they ever gave a reason, it was along the lines of "you are a special snowflake, nobody else has had that problem, so it isn't worth fixing".

Eventually, I just stopped filing bug reports.

Things aren't better with OSS, either, though I resent went bugs get closed because they're old.

Our policy with D is we never close bugs, no matter how old they are, unless we fix them or no longer have users for it (like D version 1).

> I resent went bugs get closed because they're old

I'm picturing the guy who came up with this idea sitting at his desk surrounded by unopened bills.

well, you're wrong because of all the ideas my ADHD mind ever came up with - that wasn't one of them.

While I understand your lack of success with bug reports, and I thank you for your stance on (not) closing bugs, note how the average manager got what he wanted:. A proof that reasonable effort has been made, and it's not his fault. This allows survival in a politically piosonous environment. If the bug got fixed is generally not their concern, others will have to deal with it and move on.

Besides, I once got Oracle to fix a bug. It took months and I basically had to spell the fix out to them, but it actually is possible.

Nice job! How long did you have to wait for the new software version after the bug fix?

A few months ago, one of our young devs got a PR accepted to fix a tiny little Spark bug that had been bothering us for a while. The big boss meeting was happy, plenty of virtual pats on the backs and congratulations.

And then someone had to go and ask when we'd see the fix in our DataBricks cluster.

> I have filed many bug reports for paid software over the years. The bugs were fixed exactly 0% of the time

In my experience, the big difference is buying software (good luck with getting Microsoft fixing a bug in office or windows; no one even tries) vs buying a service. If we bought specialized custom software support for some expensive hardware, those companies jump when there is a question.

They jump if you paid for a service contract. If you paid for a product, those companies owe you something fit for its intended purpose, and bugs are not that.

What's the point of keeping open bugs if you never fix them? It's not a cost free decision.

They are still problems that need fixing, some day someone may be doing work on the project without knowing what to work on and having a backlog of issues categorised by importance/etc will be useful in that situation.

It is cost free. It prevents people from filing it again. It provides insight into later problems. It provides a place where people can ask and offer advice on working around it. Sometimes an intractable bug becomes more tractable later. It can provide a clue to a later bug report. Sometimes someone new has a brainwave on how to fix it.

That would require a project be worthwhile to stick around long enough for an opportunity for someone new to come along, let alone come along and be interested in it. It's obvious that most career programmers are only used to ("interested in"?) pushing devops shovelware onto GitHub and other forms of busywork, so it shows in their bug-handling hygiene.

Have you ever filled a bug for the JDK? I was at 20 emails, plus having to create accounts and give paperwork that our company had a license for a one-liner correction of a major bug when I decided to abandon and wrap my code in an exception catcher and manage it on my side...

“ I think the general aversion to OSS is more that there is no responsible actor. In many cases, if you integrate a third party paid solution you can file a bug on that solution with reasonable confidence it can be a priority”

I know that’s what management believes but in reality it’s a complete illusion. I can’t recall a simple time where we got a bug fix within reasonable time from any of our 6, 7, or 8 figure software vendors. You get fixes only if you have paid for custom code but tickets against the actual product disappear into the void.

In contra other replies here, we have repeatedly sent bug reports to vendors and got productive, timely, comprehensive support and fixes: Hashi, Snowflake, Databricks, Confluent, and others. We're a Bay Area company of about 500 people, not a market behemoth in any way.

This is my take as well. I build and sell electronics, coded in Rust. (Cortex-M). I started using OSS HALs, device drivers, utility crates, peripheral access libs etc. Each of them had bugs, missing features, or awkward APIs. I got about 10% of my issues and PRs addressed. I now use almost exclusively internal code (with exceptions for debug tools and the cortex-m lib). If there's a problem or limitation, I fix it myself. Far easier than spelunking someone else's code, or hoping a maintainer fixes it.

Do you make the internal code OSS?

Some of it - my custom HAL is OSS, and I've published the full repo code to one of my firmwares.

And do you get any PRs/issues? Are they all solved?

I've had a few. All solved except one. I suspect only a few people are using my lib, and all are hobbyists. A particular challenge with this lib is I'm attempting to support most (newer) STM32 variants using a single HAL lib, which makes ops testing tough. (This allows me the flexibility to choose whichever variant I'd like on future projects without modifying the code base). I've published code so others can use it as an example.

Reading between the lines of your questions: I'm not throwing spears at the lib maintainers; I'm pointing out that relying on 3rd party code may cause complications. In my case, I made a decision on each individual lib.

There is a bit of a programmer trope "its easier to write code than to read it". This leads to reinventing wheels, duplicated effort, etc. When it comes to open source, I take the position that we are all in it together and try to come up with fixes for problems that I see in existing projects, even if I've never used the language before or the codebase is messy. I also think being able to work on code that came before you is a useful skill to have.

>reasonable confidence it can be a priority.

hahaha, you so funny

> I think the general aversion to OSS is more that there is no responsible actor.

Unless the OSS in question has an enterprise support subscription that is useful, the best responsible actor for OSS projects is all (or a subset of) your employees. They know your workload best and know the issues that affect you most and can learn the skills needed to improve the OSS that you use. Having a diverse set of companies contributing to an OSS project makes it suitable for a more diverse set of use cases and circumstances.

Do you think the "clueless middle managers" the OP alludes to view themselves as such? Or are they too protecting their teams so they can get real work done?

We all see ourselves as the rare exception, the one bucking the status quo and doing things differently.

Thank you for this. We have someone just like this who went into management for the same reason. He does an excellent job of it, I only wish everyone shared the appreciation for his powers of insulation and fighting in the devs' corner all the time.

Quite often your efforts aren't visible to everyone, but it's visible to some and they're thankful for it!

Echoing this. Please for the love of God get your MBA.

Its really, really easy. If you think weekend courses are going to be too much because you remember Engineering in college, I can tell you from experience that they won't be.

Agree. Getting my MBA was way easier than my CS degree.

MBA is a walk in the park compared to CS. Seriously.

I did business school before comp sci, and then a MSc in CS and it got easier along the way, so you may just have gotten better at the game of school

A Masters in CS is easier than the Bachelors.

It may be "easy" but unless you're in the right program at the right time in your life, and most importantly, have the right career trajectory, the MBA itself won't magically "open doors" into an executive suite. Certainly it's not any faster than just painstakingly climbing the career ladder.

It depends on why you want to get a MBA. If it's for credibility - go to a top 10 school. If it's to learn - you might be better off learning on the job than taking weekend courses.

A weekend MBA from a nowhere school has very little value.

> without the hassles of things like kids to take care of

That's not accurate. At 35 there are young kids, maybe even 45. At 50 they're pretty much independent, at least aged 10-12. So actually, if you hire a 32 year old dev you should be more concerned about kids than if you hire a 50 year old. So if that's the concern, only hire 18 year olds I guess, or maybe even 15.

Actually if you hire 25-year-olds, they're probably going to start having kids right around the time you need them the most.

yeah, but the plan is: lay them off once they start having kids, and hire new 25-year olds.

source: 25+ years experience in this industry.

Consulting industry?

Can believe it. But: you don't need the whole industry. You need to find one good place to work in. Those exist. May it pay a bit less than soulless corp? Sure, maybe - or maybe not. But my 25+ yr experience shows they do exist.

The spread is quite wide. I got my first kid at 45 and now almost 50 working 75% to take care of two kids the rest of the time.

The flip side is that I have never been so focused during working hours as now. I’m getting quite much more done in six hours than I used to get done in eight or nine.

Yes I feel more productive than many of the younger, childless colleagues at work. In fact I really don't like going to the office due to people talking WAY too much. I have 8-9 hours and then I need to pick up my kid, not using those 8-9 hours to the fullest is something I simply have to avoid. And incidentally my least productive days are the in office days.

> a 25 year-old developer is the same as a 50 year-old developer, but at half the cost and without the hassles of things like kids to take care of.

I was a fairly good programmer when I was 25. I'm a MASSIVELY better programmer at 57 than I was back then. My memory is a bit worse, and for certain kinds of problems, I may be a bit slower than I was at peak (maybe around 42-47). But hire me now, and you'll get a better programmer than you would ever have gotten from this body in the past.

And, guess what: no kids to take care of because they've already grown into fully fledged adults and lead their own lives.

One problem in these discussions is the curve of value delivered by an individual developer in a particular situation is short-and-wide and while I agree the senior developers are on a curve shifted to the right, there’s a massive amount of overlap.

Most company’s best 5% 25 year-old developers are probably creating more value than their median 50 year-old developer, even though that median senior dev is creating more value than the median 25 year-old.

> One problem in these discussions is the curve of value delivered by an individual developer in a particular situation is short-and-wide

I kind of disagree with this, although I don't think it's age that separates developers. But developers who can work independently are a lot more valuable than those that require close supervision, and those developers are considerably more value than those who are actively destroying value.

If I understand your comment correctly, I think we're agreeing (that there is a wide range [high variance] of value delivered across the population: think of a bell curve that's "smooshed" down to be short and wide).

Quite possibly. I realised after I posted that I wasn't quite sure what the axis of your plot were (I'm still not).

X axis is value delivered per engineer, increasing with X.

Y axis is a histogram of “number of engineers producing that value”, increasing with Y.

This, but for value instead of IQ: https://en.m.wikipedia.org/wiki/File:IQ_curve.svg

Yes, when you look at those differences any performance drop due to age is going to look tiny in comparison.

What I have found though is a lack of willingness to put up with bullshit. Stuff I accepted as normal in my twenties I'd just walk away from now. This is probably good for the employer but maybe not for your immediate manager.

“ But developers who can work independently are a lot more valuable than those that require close supervision, and those developers are considerably more value than those who are actively destroying value.”

True. But most people reach that point after a few years or never.

Yes, you hit the plateau of that curve pretty quickly. You can't just be an individual contributor and justify 3% raises every year for 30 years, when you hit that plateau on raw skill you need to start finding ways to player-coach the generation(s) of more junior developers behind you. I don't think that necessarily means you have to move into management, but it does mean broadening your definition of impact beyond LoC/commits/tickets.

1.5 to 3.0% of those 3% raises are inflation/cost-of-living adjustment, which seem like they should be able to continue forever.

> broadening your definition of impact beyond LoC/commits/tickets.

Is this the 'classic' expectation for a dev? Where I work the least technical person is the PM and everyone else comes together to determine what gets done and how it gets done.

Everyone knows the tech side and decisions gets filtered down to the rank and file. Taking initiatives are expected - I know this is likely the exception not the norm, but I hope future workplaces are more like this and less like that.

>One problem in these discussions is the curve of value delivered by an individual developer in a particular situation is short-and-wide and while I agree the senior developers are on a curve shifted to the right, there’s a massive amount of overlap.

This can also be said of managers. Then why aren´t they discriminated by age too?

Because they are smarter and work the system. Same for sales guys, lawyers and so on. They work the system to their advantage. Developers are one of the few groups that believes in a just meritocracy.

Agree about the value curve. Most developers do stuff that can be learned in a few years and then they just repeat the same thing with slight variation. There are really not that many jobs where you get challenged to grow throughout your career. It’s just repetition (like most other jobs)

Also known as "1 year of experience, 12 times" (or "2 years, 6 times")

I frequently hear that, but in practically every other profession doing the exact same thing for 20 years is still valued. And the underlying reality is you can’t do the exact same thing for 12 years in the computer field. Experience is all the little edge cases that cropped up over time.

"Experience is all the little edge cases that cropped up over time."

Absolutely. I will be using this one.

This is not exclusive to dev work. Same can be said of managers.

Anyone in the trades is doing such a job. If you're a plumber, or electrician, or cabinet maker, or framing carpenter, or a mechanic, even if those 12 years (or 20 years or more) seem similar to people outside the field, you're learning all the time. It never stops, until you do.

It’s not like learning stops but the curve flattens out a lot. Another problem is that in tech 20 year old knowledge is worth way less than 20 year old knowledge in for example cabinet making.

> Another problem is that in tech 20 year old knowledge is worth way less

This is a widely held position, which sort of makes it a self-fulfilling prophecy. But I'd argue that it's not true. Most of what I know now that is really valuable isn't related to the technology of today or 1986. It's related to how to work, how to design systems, how to decompose problems, how to scale, etc. etc.

I refer to my resume as "a graveyard of obsolete technologies"

I could do the same. But really, it's also my value proposition. "What's that you say? Your org has a dozen crappy systems of questionable lineage and you need to migrate to SomethingFromThisDecade? Let me pick it apart for you and we can build a plan together." It's not much, but it's honest work. (and I happen to enjoy it...so win-win)

You might be surprised at how many companies are running 10+ year old technologies that were designed around the constraints of the 10+ year old systems that they replaced. If that's your thing, you can build a pretty strong career around being the person to keep that system humming along.

But this happens in tech management too. Last 20 years: CMMI? RUP? PMI? XP? Scrum? Design Thinking? Project to product management?

I’ve worked with a lot of young developers and never met a 25 year old developer that’s creating more value than the average 50 year old developer with 20+ years experience. In theory sure it’s possible, but in practice it simply doesn’t happen even close to 5% of the time.

The thing is most people quit the field long before putting in 20+ years. So, I suspect it’s less about the experience than the filtering process.

So senior devs are better than 95% of 25 year olds.

Since finding a "best 5%" is almost impossible, because who knows until you hire them and they work there for a while, the best bet is to hire people who are older. Also, for a bone fide best 5%, they are going to work at the cool companies, and never will work at a sewer processing government utility company in their IT department, or work at for a local chain of tire stores with 50 locations and an IT staff of 3 people.

So, one might as well not even worry about the top 5%.

Recently Ford was in the news here in Michigan regarding layoffs. They found emails saying if an employee is over 55, have a career of large success and as a result are paid above average then lay them off.

Ford is facing huge challenges as the entire industry has to pivot to battery powered vehicles and they want to get rid of their best and most experienced people?

This will not end well for them. I'd be just the opposite and try to convince these folks to work until 75!

That sure sucked but this was not about the age but about the cost.

They wanted to fire the most expensive people. In union shops seniority tends to go in hand with higher pay.

And I'm guessing their thinking was that the closer someone is to retirement, the more likely they are to accept a payout offer.

This is likely a direct result of the EV transition. They now have a lot of people with 30 years experience that’s seemingly irrelevant.

These days, there is no excuse to have a non-technical manager (unless you are a technical manager yourself). Software is eating the world; it is professional negligence to put someone in charge that doesn't have a detailed understanding of the technology that impacts everything about the modern workplace.

It isn't like there is a shortage of technical managers right now.

I've never had a non-technical manager, even when I worked in sales, and I've been doing this for over 20 years.

This must be industry variant then. 3 of my 4 jobs in the last 30 years have involved non-technical leadership. The exception was working for a "tools" company where software was the product. But the other 3 are at the "edge" where software enables real devices to be more modern/gadgety. In that context, software programmers are a necessary evil to en-smart-ify gadgets that have traditionally been "dumb." And letting software people be part of the direction is too much of a loss of traditional power.

That’s why I recommend that young people should try to work for a company where the CEO comes from a tech background and understands your work. It’s just natural that someone has more respect for a role they have performed themselves.

Why do you recommend this to young people specifically? Wouldn't it be sound advice regardless of the age of the recipient of this advice? Just curious why you've added that qualifier.

I guess i don’t give advice to people my age ;). getting into tech companies also seems easier when you are young and don’t have much of a resume. Having a resume with years in not interesting companies and uncool tech also seems to make you toxic.

Funnily enough some of my better managers have been non-technical. Some of the worst have been people who know enough to micro-manage you to death.

tbf, micromanaging is bad regardless of any other attributes.

The young MBA people are intimidated by people who can reject their schoolbook ideas coherently. Most of those people are older, but not all of them. I started noticing this before I was thirty, either reacting to me or to someone I agreed with who happened to be older. It only gets worse.

> increasing number of managers who have little to no domain knowledge

I think it's on the downward trend though.

Where I work, more managers than not used to be an engineer, and the younger they are, the more likely they're going to used to be engineers (or straight up converted).

Isn't the trend against this approach? It seems at least in tech, the view is that this is not so good.

Reply on news.ycombinator.com