Hacker News Reader

Comment by micaksica | Hacker News Reader

I am not really "old" (ie over 40), but I have interviewed older candidates for some technical roles at very different companies, and I've found there are either old people who believe they know better at everything whose skills have not improved much since their early 30s, and then old people who stay up to date on technologies, trends, and realize that programming is a field you never really ever master with time or age; it shifts too much to be able to ever fully grasp it.

The "old" people who are curmudgeonly and stuck on older technical stacks are the ones who don't fare well. The ones who are current in skillset never seem to have an issue and generally impress the people they meet, as they bring both experience and current technical knowledge to the table. Anecdotally, I would say 8/10 of the 40+ crowd I have interviewed fall into the "old technical stack" / "i know better" crowd, and I think these are the ones that poison the well for the good guys.

I am beginning to believe that the trick to software engineering as a career vs. management is to stay current above all else. If you let yourself become obsolesced, you will be thrown aside like an old PowerBook. That's the reality of the technology industry and has little to do with age.

View on HN

The older I get the more I realize how these old curmudgeons were often right. They've been there to witness the cycles of technology and aren't impressed with the shiny new ones that are often worse than the old ones. They aren't interested in the cloud because it's modern day mainframes for instance.

Lately I've been taking a look at a lot of older tools and being pleasantly surprised by how capable they are compared to modern ones. I started coding professionally in a world of virtual machines and xml files, now where moving back to native compilations and json. Eventually we'll rediscover ini files and how there even simpler than json and we can avoid the curly bracket tax. I've used every build tool under the sun but recently discovered that make was simpler and better than anything else I've used. We've gone full circle on ORM's and now writing sql is in vogue again.

I wish I'd learned more from those guys much earlier.

We're so eager to justify arbitrary technical fads. Use something until you have enough experience to start seeing its flaws, move on to something shiny and new and perfect until you've used it long enough to see its flaws, repeat.

> Use something until you have enough experience to start seeing its flaws

I think we've been completely skipping this step for the last few years.

You can very easily find yourself in a situation where every project is either your first in technology X, or trying to maintain something that was someone else's first attempt at using it. "Legacy" means "proven in production and making the company money" but too often these days it is seen as a dirty word.

> The older I get the more I realize how these old curmudgeons were often right. They've been there to witness the cycles of technology and aren't impressed with the shiny new ones that are often worse than the old ones. They aren't interested in the cloud because it's modern day mainframes for instance.

This is actually one of my biggest career problems. I mean, it's an advantage, too... I can pretty quickly understand new things, because they are similar to old things, but... on an emotional level part of me rebels from the new cool thing simply because the old thing worked, often more reliably, and this new thing? this new thing has a bunch of little subtle differences and bugs that I have to learn and deal with and fix, just like the old thing had a decade ago, so my natural reaction to the latest fad is usually a negative emotional response, and pointing out that it's essentially the same thing as the old thing.

This causes obvious problems, of course, with the people who got promoted for "demonstrating complexity" when they wrote or implemented the new system.

I need to learn to point out the similarities to the thing I know, but to do so without the negativity, because, uh, cultural fit. (so bitter!)

>They aren't interested in the cloud because it's modern day mainframes for instance.

This is the opposite of true. Mainframes were all about complete reliability; you can always rely on the hardware, or at least that's what you are paying for. "The cloud" is all about the chaos monkey, about writing your application to deal with any server failing (or returning nonsense) at any time.

The disillusionment with "the cloud" comes from having to deal with managers who think that "the cloud" means reliability, when it really means "write your applications so they can deal with hardware that is significantly less reliable than hardware managed by in-house sysadmins"

re: Chaos Monkey. I love this, and I'm 48. 99.999% uptime meant that once a year your program did something completely disastrous because the server flunked.

Assuming our hardware was reliable was a mistake. Writing code so that it's chaos-monkey-proof is a great step forward.

As for the generational thing... meh, we're ugly. People like hiring the beautiful folks. Startup folks think they're immortal, having some greying old fart in the corner wheezing away reminds them that they're not.

They should hire us for remote work! :-)

Chaos Monkey is actually a reference to a tool that I think netflix released? huh. yeah, I see it on github:

https://github.com/Netflix/SimianArmy

I remember someone giving a talk on it in the mid aughts, and I think it's a wonderful way to describe what happens in real-world networks and systems.

>Assuming our hardware was reliable was a mistake. Writing code so that it's chaos-monkey-proof is a great step forward.

Hah. Part of it is that I am the guy who is responsible for keeping that multi-year uptime (and on most of my own hardware, this is mostly a matter of vetting updates, security and otherwise, and implementing workarounds) - but I like to point out that building a system that can deal with the chaos monkey is... well, it's way harder than throwing up a reliable SQL server with a reliable backup and someone like me on pager. Especially if you want to beat the "the system fucks up once a year" record that even mediocre server-grade hardware can achieve.

That said, if you can write such software, I agree that the end result is better, I mean, like half my skillset is in Linux/BSD and environments where reboots cost big bucks, but I'm not going to cry about turning in my pager. I'm just saying, it's hard and most people screw it up and end up building something less reliable than well-managed hardware with a competent oncall.

>As for the generational thing... meh, we're ugly. People like hiring the beautiful folks. Startup folks think they're immortal, having some greying old fart in the corner wheezing away reminds them that they're not.

Eh, I think that most of the startups that only hire pretty people also tend to pay such that they can't afford someone who is good who has a few decades of experience, so it might be more of a budgetary/age thing; young people, generally, will work for less.

I think it might also be a San Francisco thing. The fitness of the people interviewing me goes up and the wages they offer me go down when I head up that direction.

The strong impression I get is that it's a seller's market for programming work most places in the United States, but a buyer's market in and around the Bay Area. I've never worked there myself, only visited, but I have known a lot of folks from there with hair-raising tales to tell. Things seem a lot more equitable elsewhere.

Eh, I'm contrasting San Francisco, above, with the South Bay; both are "bay area" (conventionally, the south bay is "silicon valley" - historically, San Francisco is not "silicon valley" though that definition seems to move every bubble.)

In the South Bay, I largely don't have cultural fit problems, and I can pretty easily score pretty good jobs at second and third-tier companies (getting jobs at top-tier companies is a real challenge, still, but considering the compensation and prestige at the end of that particular tunnel, I can see why.)

In San Francisco, though, I quite often have 'cultural fit' issues, and often can't even get into startups that pay really poorly.

On the other hand, most places don't need that level of reliablity. If a company email server went down for a few hours it's not that big a deal. Even for most large corps, only a certain few things need that level of reliability.

I often see it get written into contracts with very little thought as to what it means. You get some great looks from managment when you break the figure down into minutes though, especially when you don't have 24/7 staffing. A poorly timed cosmic ray could ruin your SLA.

* It would where I'm at now, because someone thought it would be a good idea to handle a critical business process by emails csv's.

I've also seen people make the other mistake, though. I've had people screaming about 2 hours of downtime violating our 99.999% SLA, apparently not realizing the five nines means the thing can be down eight hours a year (an entire business day) and still be in spec.

That's not true. 5 nines, ie 99.999% uptime means that the maximum downtime in a year is about 315 seconds:

60x60x24x365 x (1 - (99.999/100)) = 315.36

Wikipedia confirms: https://en.wikipedia.org/wiki/High_availability#Percentage_c...

So yes, 2hrs of downtime would most definitely violate the SLA. The 8 hours you refer to is the figure for 3 nines.

D'oh. It was three nines, thanks

RE the cloud/mainframe comparison. I was thinking more of the centralization aspect. The web seems to have gone from this vast network where anyone could set up their own server, everything was decentralized (except DNS which was the source of quite a few debates) and no one had any sort of control over it. Now much of the web seems to have condensed into a handful of data centers and we've given too much control to a few companies. The recent cencorship of twitter (and now youtube) really crystalized this for me.

On the other hand I see things like docker (I was late to the game here) and even though everyone seems to be focusing on the cloud aspect I can see it being a brilliant tool for decentralizing again. The tech could easily be leveraged to make things like setting up an email server possible again for small companies or families.

> I need to learn to point out the similarities to the thing I know, but to do so without the negativity, because, uh, cultural fit. (so bitter!)

If you work it out let me know ;) It feels like I've spent a good chunk of my career doing this and I'm only 10 years in. The old reliable tools have all be on the same platform FFS.

Its likely that someone who says "NO" all the time is right some of the time and its fair that they get credit for being right. At the same time, they need to be held accountable when something they said "NO" to turns out to be a really big deal. Im sure someone said Java is a fad when it was launched or that python was useless and so on.

A lot of people were saying no to java, at least on the consumer desktop which was one of it's first big aims. That's one of the thing's that young, naïve me put down to old farts being out of touch.

Two decades on their C/C++ win32/x apps are running and no one has java installed in their desktop to run mine. They have every reason to be smug.

.Net is pretty much Java. So after all the legal and marketing turmoil young you was basically right.

They hype around java was being cross platform and making the OS choice irrelevant, .net had the opposite effect.

When I look at all the apps installed in my computer, very few are .net apps.

Obviously Java didn't succeed as a desktop application development language, but the JVM and the java eco system has succeeded by any objective measure. I see your point that what matters is what does a person say "NO" to.

>Eventually we'll rediscover ini files

We kind of have. They're called YAML files now.

Code is code and stacks are irrelevant. As other commenters have said, curmudgeonly old guys say, "I know better" and quite a few of them do ;-). But I think get get your point.

The other day, a promising young programmer asked me how to deal with the overwhelming load of new frameworks. Which ones should he learn? Which ones should he ignore? What should he do if he picks the wrong one? How will he know?

In my opinion, it really doesn't matter as long as he is learning something new. You only get stuck when you try to stick to the things you are familiar with. You need to keep stretching yourself time after time.

If someone says to me, "Do it in Python", "Do it in Elixir", "Do it in Haskell", "Do it in Go"... it just doesn't matter to me. I've been through that blender before a hundred times. In fact, that's precisely why you would pick a guy like me. I'm not trying to keep up with the current trends. That doesn't matter. But I'm also trying not to hang on with a death grip to what little I know.

On the other hand, if you need some guy who knows every single detail of how Rails works, hire a young guy who has only ever worked with Rails before. You need a mix on a team. Pair him up with an old guy so that he gets some perspective before he burns out his career.

> curmudgeonly old guys say, "I know better" and quite a few of them do

Oh, absolutely, we often do. But, like the ancient kungfu master trope, you can't tell your juniors this directly, it's a realisation they have to reach themselves. Sometimes while being smacked in the face by the consequences of not listening.

(More seriously, being a curmudgeon doesn't help; being a mentor does)

Making generalizations from a set of interviewees is very risky - because interviewees are very, very different from the general population. I should know because I recently made this same error.

Background: Current company recently got series B, and I'm trying to aggressively scale the engineering team. As such, I've been rapidly phone screening candidates at a much higher volume than usual.

After screening the first set, I began feeling very sad about the current state of software engineering. The average age was probably about 27. All had CS degrees. All were experienced Java developers. And, yet most did not know the difference between a long and an int. Most couldn't describe the differences between linked lists, arrays, and hash tables. Most could not explain how to make a block of code thread safe. Most could not describe how an interface is different from a class. Most could not explain the difference between value passing and reference passing.

I was so aghast. I mentioned in passing to a co-worker that computer science degrees must have become so dumbed down over the last decade. But, then I realized my mistake.

Of course these interviewees sucked! Very few of the good candidates were looking for work. So, I was only seeing the worst of the worst - not a random sample.

> Of course these interviewees sucked! Very few of the good candidates were looking for work. So, I was only seeing the worst of the worst - not a random sample.

Another thing I've seen many times is that the listing either wasn't written well, circulated in the right communities, or that details like compensation or the environment scared off people with better options. That can be a very delicate subject to bring up because many places don't want to admit that the problem could be their business rather than the candidate pool.

Yep - odds are so low to find someone decent.

Let's say you're a good, experienced developer. You get 10 recruiter messages per week. You ignore most of them but 1 in 20 you decide to read. There's a 10% chance that the description looks like a good fit. You contact the recruiter and tell them your salary requirements. There's a 15% chance that it's in your range. You decide to set up a phone screen. But, since you're valuable to your current company, you're extremely busy. There's a 20% chance that you can make the call.

I'm too lazy to calculate that, but that's a huge number of people to contact just to phone screen one good person.

> Making generalizations from a set of interviewees is very risky - because interviewees are very, very different from the general population.

While I agree with this statement, the ageism I think is plaguing the Valley is an interviewing/HR/hiring issue, as it is in that process that their confirmation bias is being reinforced there when they bring the old dogs through the door.

FWIW the best engineers I have ever worked with, in my opinion, always seem to be the ones ten years or so ahead of where I am. They're the ones I am always learning something from.

>> If you let yourself become obsolesced, you will be thrown aside like an old PowerBook.

There are many large companies (mainly, banks and card corps) paying really, really good salaries for people with 30+ years experience with COBOL, JCL, REXX and the like. You know, mainframe stuff.

Obsolescence is in the eye of the adolescent, if I may be so bold.

You know, I always heard this, and I have kind of a morbid fascination with old mainframe technologies, even though I've never used any professionally. So I looked pretty deeply into that job scene. Turns out the vast majority of the jobs hiring for COBOL etc pay 70,000 to 80,000 a year. It's not bad pay in some parts of the country, and the hours are generally reasonable. But they're not really, really good salaries.

It pays sensibly because it's a job that really needs to be done, but it doesn't pay too well because it's not a rocket science and it's easy to find somebody who can be trained to do it.

I worked in one of those roles for a year or so, though in the UK. From the salaries you quote, I assume you mean the US? In the UK that sort of money is quite good.

The salary you quote, converted to UK money, is about right for entry-level roles. I was hired in that company at a graduate level and I had no experience of mainframes whatsoever when I got the job (which I hunted down out of the same morbid fascination you mention).

My older colleagues though, the ones with 30+ years experience, they would be getting much better money than that. It would depend on the position also, but I heard of at least one graybeard who was asked back from retirement, because the company couldn't afford to lose his expertise.

Now, I don't know what they paid him, but I'm pretty sure it's what I call a really, really good salary.

+1 Exactly right. I am in my 60s and I have a satisfying consulting business, occasionally being an employee, but mostly consulting over the last several decades.

My formula is to spend at least 15 hours a week on non-billable learning projects, writing technical books, etc. A lot of this time is simply reading papers in my areas of interest (deep learning, functional languages like Haskell, application of deep learning to NLP, etc.) and writing enough code to make sure I understand new technologies.

I get hired because I stay current.

It sounds like your idea of staying current is different from what others are talking about in this thread. Do you keep up with the latest JS frameworks and nodejs? Rails? There's a distinction to be made between learning new things that are actually useful (deep learning, NLP, new programming paradigms) instead of learning the latest framework just to do something we could already do with another technology 5-10 years ago.

When I used Rails (a long time ago) and Node.js (last year) for work, then yes I did get up to speed on both of them and enjoyed it.

I agree that core technologies like linear algebra, machine learning, etc. aren't the current topic. The main thing is to learn new things, and as someone else here said, maybe it does not matter so much what you learn as long as you learn new things.

This is true for all ages and categories; there are good and bad younger programmers, good and bad middle-aged managers, good and bad grey beard *nix sysadmins etc.

Oh, I agree. I think there is a definite issue of people ascribing "old dogs, old tricks", and that bias is the hard thing to overcome. It's especially hard when a lot of people are confirming that.

It's the age equivalent of https://xkcd.com/385/ . When it's a younger person, it's "this person can't code for <x> because they don't have experience." It's harder to quell that cognitive dissonance when you don't have that out and forces you to place the blame on incompetence.

There's also a definite issue of people ascribing "every older time was worse".

Thinking about it, I find that I straddle the line on this. I'm up to date on the New Shiny and will happily run with whatever flavor of the month language, framework, and programming paradigm that a given gig wants. Yeah, sure, Node.js with tons of functional stuff mixed in pulling from a NoSQL store and React on the front end. I'm your guy. We're gonna change the world!

But for my own stuff, there's no way I'd use any of that crap. Good old C#, SQL Server and a proper boring stack and tool set that I know won't just up and fall over on a Saturday morning and leave me debugging NPM dependencies all weekend instead of bouldering in the forest with the kids. This stuff is my proper income stream, and the most important thing is that it works. If that means I have to write a "for" loop and declare variables and risk 19 year old kids snooting down at my code, so be it.

But yeah, the key is to never get so far down in to that comfy hole that you can't hop back into the present day when it's time to talk shop with the cool kids.

What do you use for frontend development then? Raw JS? Jquery? Flash? :)

Yeah, mostly just javascript, with the occasional bit of jquery thrown in. Like I say, I've been quite deep in to various front end frameworks and scripting libraries and learned what is useful and what to avoid.

Turns out you can get a lot done when you don't have to constantly fight with terrible 3rd party javascript.

So really age doesn't matter - experience and aptitude does. Here's your quote minus references to age.

"I've found there are either people who believe they know better at everything whose skills have not improved much, and then people who stay up to date on technologies, trends, and realize that programming is a field you never really ever master with time"

Yeah, for the vast majority of engineering programming is like selling shoes. You just need about 4 years experience and you pretty much know it all. Certain skill sets are great for older folks though. Security, for example. You want to work with someone who has a long track record of being trustworthy.

That being said, there is something compelling about an older engineer who constantly re-invents himself with the latest technology.

> Yeah, for the vast majority of engineering programming is like selling shoes. You just need about 4 years experience and you pretty much know it all.

That's the point I'm trying not to make. Are you building a startup that's effectively a CRUD app? If so, sure, that's pretty much all you need and is why coder schools have become so prevalent - they get you to a practicing point that covers the bases of most small websites and very, very basic startups.

Age and experience brings with it something vital: the ability to build long term pattern recognition of technology business cycles, the "all is old is new again", the ways that novel technologies may fall like their predecessors. This is not something you learn in a CS program or even a few years out of college. It's something you only learn by playing with tens of languages and mastering six or seven over decades, by constantly learning, by being part of those business cycles. This skillset is often discredited and is enormously valuable, but I believe it requires a tireless passion for novelty and modern technique to become a multiplier on skill.

Experience is more important if you are actually developing algorithms rather that making another app. It takes time and practice of genius to get a handle on required mathematics for AI, adaptive systems or advanced data structures. It is no accident that mathematicians are divided into super young genius and old bearded wizard camps.

I disagree with "This is not something you learn in a CS program". Anyone who has taken a SICP course will know "all is old is new again". But in large I agree with you.

You will never "know it all" about programming. If you seriously think then you can learn all in 4 years I'm really wondering what kind of things are you working on.

Node, Mongo and Angular would be my bet.

> You just need about 4 years experience and you pretty much know it all.

No. After four years you know just about enough to inflict a really nasty case of the second-system effect on some unsuspecting customer.

I have been programming for 30 years. I can look at code that is 10 years old and see how much I have improved in those 10 years. 26 year old code? It was a joke. I thought I knew it all back then, but for about the last 20 years, I have been working with the realization that I know less than 10% about this field. Your statement cannot be true unless you only work in the very limited scope of CRUD apps. Even then, you probably still have a lot to learn about SQL optimization (I know, you use an ORM and do not worry about those pesky details:<) I am continuously amazed by the poor quality or performance of a lot of commercial software, probably borne out of hiring practices that espouse the same belief you do.

There is a difference between being able to write code and being able to write nice maintainable code that is easy for others to understand. It took me a lot longer than 4 years to reach the second stage.

(Could guess that one will provoke reactions ;-))

My biggest to date (but not the only one): having received complaints, I figured in 2 days that the culprit is the change in the manufacturing-workweek-number of the DDR ICs. It took them several months onsite with people travelling from abroad and with expensive equipment to find the real root cause, and guess what they have found?

And I am not even a hardware engineer. How did I do that? Intuition. You need lots of time to develop intuition, much more than 4 years, and once you got it, it saves lots of time and money.

I have also seen other experienced engineers do this sort of tricks, and I pity the workplaces where people aren't familiar with this.

My observation is that most devs get stuck in their favorite stack no matter what their age is. A lot of younger guys I talk to are stuck on node.js or whatever is cool right now and can't be bothered to consider alternatives either.

I think there is just a large percentage of people in tech that do it to make an income with the least amount of thinking. Only a small percentage is really interested in the technology.

Reply on news.ycombinator.com