Old Geek
tbray.org
tbray.org
Perhaps this is an unpopular sentiment, but after 33 years of programming I have been observing more and more how many elements of a supposedly hyper-rational field function like religious beliefs or memes. I suspect that one reason people prefer working with young programmers is -- sometimes -- that they don't want push back on the beliefs that are underpinning their enterprises. To take a few simple examples, people with a lot at stake don't necessarily want to be told that something will probably take 3x longer than they think. Or that there are some philosophical issues at play in their strategy.
A truth that can hurt: people generally only consult nerds when they believe they have no other choice. To many people this means they only want programmers for "code monkey" style coding, i.e. I think there may actually be preference for inexperience in the wider world.
I'm sure age will take it's toll eventually, but in my case there is no doubt in my mind I write better code now than, say, 10 or 15 years ago.
Fortunately, there's a solution: freelance and work for people without these biases. It seems like there is no shortage once you leave groupthink environments behind.
To use an analogy, I refuse to believe the roads would be safer with a bunch of drivers all learning while they go.
Its not like many of the new languages are THAT much different. 90% of work is still done in C, C++ and Java
when learning new tech now i find myself determining best practice pretty quickly and it's very comforting (like whoa, how did i know this!). I was never a fast code ninja, and now even less so, but can generally come up with a stable implementation of v1 that will run in production with no surprises and even email me all relevant details if there is a problem. I realize that this is more suitable in corporate style coding than startups which need to test ideas fast and evolve or evaporate.
Then when it does, they blame the programmers for being "bad" and make posts about the dangers of "false positives" in hiring.
I have never considered software to be a rational field (or "art"), I think that is just one of the myths we tell about ourselves. It's its own thing, with bits and pieces taken from many other human endeavors, honestly that's why I like it so much.
> This is idiotic. People over 40 trade one set of skills for another (source: I'm over 40). You lose short-term memory, can't juggle too many things simultaneously, and aren't always up to date on every latest fad. But what you gain is fantastically valuable: intuition, abstract thinking, systems thinking, ability to detect patterns in large systems, ability to notice that certain problems have been solved in a different field, and lots more. As I grow older, I notice these changes, and while I do regret not being able to remember IP addresses after switching to a different window (get a larger monitor, or just copy&paste), I am very happy with the overall shift.
To put this in other words, as I age, I found that yes, I do have less ability to do brilliant-late-night-ninja-coding stunts, but overall what I gained translates into Getting Things Done. Which is why I find this ageism trend mindboggling: is there a CEO out there that doesn't want his company to Get Things Done?
To give a tangible practical example: I just wrote and launched PartsBox.io (https://partsbox.io/) as a side project. I could only do it in the time constraints involved because I knew which shortcuts I could take and which code I should not write. My 25-year old self would likely have written brilliant ninja code (that no one would ever see), but would never have gotten the project shipped.
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"
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.
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.
> 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.
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.
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.
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.
If a manager doesn't think you will be up for a 36 hour shift, maybe they won't hire you.
Do you really believe this is true? Do you think general industry culture reflects experience and maturity? No, it is the exact opposite!
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.
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.
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.
You are absolutely correct: You should only go if you are interested. But if your alternative is to be jobless....
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.
I think I'm more similiar to what you describe about tourself than about young devs.
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 :-)
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.
My time is almost over.
Or so it's been explained to me.
I moved the decimal point one place to the left and now I have a version:
I am version 4.7
Apparently by the time I'm version 6.5 my codebase will be a little bloated.
---
On another note, this age subject has come up a few times:
Programmers: Before you turn 40, get a plan B (2009) https://news.ycombinator.com/item?id=9361580
Silicon Valley’s Dark Secret: It’s All About Age (2010) https://news.ycombinator.com/item?id=9710936
I also wish I could copy paste this comment I already wrote: https://news.ycombinator.com/item?id=9362508
While I might miss specific events or groups I was part of in the past but I never wish to go back in time. It takes so much time and effort to build yourself and your life moving forward that going back would be a waste.
Thanks for the idea! It has solved a long time puzzle :)
To preserve versioning semanticity, gotta habitually push out new code. Gotta strike the balance between squashing bugs, polishing UI interactions, testing new features, and self-refactoring. Gotta avoid feature creep, observe deprecation roadmaps, ensure social network integrations are in order… all those routine things.
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.
That being said, there is something compelling about an older engineer who constantly re-invents himself with the latest technology.
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.
No. After four years you know just about enough to inflict a really nasty case of the second-system effect on some unsuspecting customer.
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.
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.
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.
I think we've been completely skipping this step for the last few years.
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"
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.
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.
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.
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.
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.
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.
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.
When I look at all the apps installed in my computer, very few are .net apps.
We kind of have. They're called YAML files now.
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.
Turns out you can get a lot done when you don't have to constantly fight with terrible 3rd party javascript.
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.
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.
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.
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.
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.
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.
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.
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)
"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"
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.
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.
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.
<- Ex Amazon engineer.
That being said, there are ways to succeed as you age. Working at amazon is not one of them. Specializing in engineering areas that require a track record of deliverables is. It's Bayesian probability. That is what your advantage is if you are old.
Being trustworthy helps in things like security. Young kids between the age of 16-25 are freakin random and they might be the next snowden for all a manager knows. Older people who have never done anything irresponsible in their life can benefit here.
Also, leveraging technologies in your resume that are once again fashionable. Devops in the cloud, neural networks in deep learning, etc.
Is any of this fair? Of course the F not. But neither is being discriminated against because you're old.
Perhaps you just had a bad experience and blame the entire company for it rather than the particular situation you were in.
I now work with 3 SDE3s between two related teams. Meanwhile, a friend and sometimes mentor of mine just got his PE promotion. I honestly take offense to the notion that he didn't deserve it, that he bribed his way into it. Fantastic developer and well deserving of the title.
Many of my bosses have been 5+ years younger than me.
I am eyeballing jobs that are paying exactly what I got paid 8 years ago, just because they are local/family friendly.
I am not experienced enough with management or executive roles to take one.
I am too much of a generalist to get a senior role in a given field, except the one field I specialize in, which is fairly useless when it comes to paid jobs.
I'm not a competitive coder, but I can meet any reasonable deadline. Unfortunately, the trend is now to value the former much more than the latter because it is easier to measure in the interview process.
The majority of jobs out there (frankly) do not require much skill for functional results, so there is someone out there 10 years younger than me who can put in more time for less pay.
Additionally, there are people with 2 or 3 years of industry programming experience making over $250k. It sets a weird baseline that makes it impossible to scale up for more experienced coders.
The most elite people in the valley struck it rich fresh out of college. These are the people who dictate the flow of cash in the software world. What reason do they have to believe that an old software engineer is valuable, even as they themselves grow older?
I don't expect the world to be fair. But I feel like there has to be some sort of value in experience?
But something doesn't add up here, does it?
I'm only 36, but my personal experience would bias me to assume it is because the companies that would pay market rate aren't willing to even talk to them. It's hella illegal, but I would not be surprised if a company basing their product on technologies that are only 3 - 4 years old is silently, perhaps even unconsciously, ignoring resumes from people with 15+ years of work experience, even if they have the experience in those recent technologies.
It would bother me, but I know that ageism is one form of discrimination that eventually hits us all. Beware, young people. The rationalization you do today will be used against you in a couple of decades. And you'll know better then, but you're not listening to the gray-hairs today, and probably neither will the people refusing to hire you then.
Fortunately, some companies treat their gray-hairs better than others, and while you'd think startups were the best route of all, since no boss can refuse to hire you then, it turns out that ageism is pretty widespread, and it can be hard to get funding for a startup, and even hard to land customers if you're the public face of a startup.
Every year, we all get a bit closer to it happening to us.
This is one of those things where more visibility and discussion will eventually help, it's just right now there's a large social aspect that needs to be dealt with first. Personally, I'm very familiar with the difficulties older coders face as one of my colleagues at my last job battled it pretty much daily, and even when he took over as lead programmer for our small university, the management and even his underlings really didn't want to listen to him much either. But he was stuck - like a lot of people at the University, he wanted to leave because things were getting bad across the board (management issues resulting in enrollment loss, which means less money), but he was 50+. Since we were in the Seattle Area, this meant the only tech hiring was Amazon and other Seattle based start ups, none of which wanted a 50+ year old man, even if he could hack and plan with the best of them.
It's experiences like this that I think help shape people's perspective. A more personal experience, seeing it actually affect someone in exactly the way they described it. It would be great if we could just accept that sometimes people's biases do influence their judgement, but sometimes it requires a more impactful approach.
Indeed, it's the silliest form of short-termism.
Then again, when you're young you can't help thinking you 'll never grow old. It's what being young means in the first place.
> If you help build something important and impactful, call it X, it's easy to slip into year after year of being the world’s greatest expert on X, and when X isn't important and impactful any more, you're in a bad place.
He, of course, was co-author of the XML spec.
For Tim Bray, X is short for XML.
[1] https://en.wikipedia.org/wiki/Gosling_Emacs
[2] https://www.cmu.edu/news/archive/2009/November/nov5_goslingr...
Often people are maintaining code that is built on top of XML.
I think xml with it's great validation and inter-operability is still the best choice for something like HL7 though.
I'm 37 and just recently phone interviewed for a job with two twenty-somethings. I felt I got discriminated against not so much because of my age, but because I just wasn't into the same things as them and wouldn't have been a good 'cultural fit'. My age played a factor in that respect.
If you're cool working with old hackers, post your jobs on there for free. I'll circle back around tomorrow and make it classier.
I'm almost 30 and I'm starting to grow concerned about ageism.
Some Stats from 2015 :-
Median Age / Profession
42.1 Computer systems analysts
44.7 Information security analysts
43.1 Computer programmers
39.7 Software developers, applications and systems software
35.9 Web developers
40.5 Computer support specialists
47.0 Database administrators
41.2 Network and computer systems administrators
41.6 Computer network architects
41.2 Computer occupations, all other
I'm forty this year and still coding. I dabbled in mgmt in my early thirties and didn't enjoy it, so stuck at coding.
I am extremely up-to-date and well-versed in everything modern - like most of us here, its my consuming passion too - but I'm completely underwhelmed by the JS frameworks so I can seem a bit "not with it" perhaps?
I do a lot of architecture - I've been a chief architect for big subsystems on a small OS, even. Not that I seem to have any impact or sway on mgmt, who keep repeating the technical mistakes I keep pointing out anyway..
So here's the nub: if I moved on, I doubt I'd be replaced. Companies don't feel they need people like me. And they can have someone young, cheap, without family and without work-life-balance and without strong opinions to point out technical flaws in plans etc. They'd all probably be relieved!
Leaving us "old geeks" unemployable in anywhere near the quantities soon available...
I see a lot of these articles, which I like reading btw, about technicians, too old to do the work. [0] Let's turn this idea on it's head: What about "Management, period". Management itself a big source of company inefficiency. [1]
What technology is being created to push down the cost of executive compensation in buiness?
[0] "Just 120 of the Audi factory’s best employees qualify to work on the prestigious R8 assembly line. More than half of R8 workers are over 40. It is said that the easiest way to spot them is to look for the gray hair. The factory calls them “silverliners.”" ~ http://natgeotv.com/ca/megafactories/audi-facts
I imagine this technology would be difficult to market and thus difficult to sustain, given that the prospective customers (i.e. decision-makers who control companies' funds) would have personal negative incentives against purchasing it.
This reminds me of some friends whose startup's product was software to make lawyers more time-efficient with (billable) administrative tasks. It turns out customers don't come banging down your door to buy a product that 'helps' them make less money.
That is something I would believe, push-back from existing people in companies. What about new companies selling products? (remember ways of making money in SW: internal services, contract/consulting and product)
Other way round: business exists to provide executive compensation, and the job of the executive is to squeeze everything he (and it's usually a he) can from the investors and the employees.
The platonic ideal of a 21st-century company is a CEO and a computer. The computer hires a cloud of transient workers and the CEO pitches slides to investors. Any resemblance to Uber is a coincidence..
I like this comparison with Uber.
Anyway, I'm now travelling for a year (my partner made me quit my job ;) which has been lots of fun. I've caught up on a lot of books, playing with elixir, sharpening tools. But, I'm wondering what to do when I go back home, and finding it hard to decide. I already have an offer, and I'm not particularly worried about having work, but more about having the _right_ work. I'm not sure how many more options to change I'll have. Coupled to that, I'd like to work on projects which I feel are doing something useful for society.
Options:
1. Work remotely for a company I've worked for before. Should be decent cash. Codebase is horrible legacy stuff (but improving). Just me and another (more junior) developer. 2. Work for a pretty professional company in town. Excellent excellent team, I'd learn heaps, but it'd be just straight business work (not ticking the "useful to society" box.
I have a couple of options in both of those categories (I think ;). I've been stung before being a solo developer and I'm not that excited about being the most senior on the team. I'm an OK developer, but I know there are lots smarter, and I like learning from others.
So decisions decisions. It feels to me the older I get the fewer of these types of decisions I want to mess up.
the technical work itself is what you make of it, even learning by replacing legacy stuff with newer better stuff is always a possibility. choose to use technology that is interesting to you. spend personal time catching up on it if it's impossible to do 'on the clock'. "garbage in, garbage out", basically.
however, the conditions in which you do the work in are not under your control and carry the heaviest personal cost.
This is the thing, the remote environment would be entirely under my control and I think the work-life balance would be fine.
The non-remote job would be more challenging work, probably a bit more corporate & rigid, but have a killer team to work with and learn from.
I'm with you on the "learning by replacingn legacy stuff with newer stuff" ... that train is already in motion and there's certainly a lot you can learn by doing that properly.
Thanks for the thoughts, I'll add them to the melting pot.
A young kid, in tip-top shape stands next to an overweight graybeard. He snickers at the older fellow, confident that he will find the treasure first. The whistle blows, and off they go running. Or rather, the younger fellow goes running. The older guy stretches a bit more, buys a bottle of water, and huddles off into the woods. He walks at a fair pace, not really breaking a sweat, as he knows it's going to get hot in an hour, as the sun hits the middle of the sky. He's been in these woods plenty of times in the past thirty years.
The young kids runs here, runs there, looking for anything that may resemble the clues he was given. He is fast. He has the latest gear and newest gadget. However, he's not really sure where to begin.
The old guy has a hunch where to go. He knows where the blueberry bushes grow that were mentioned in the clue. He knows where the sunny clearing with the three rocks is. It takes him a bit of time, but he is going in the right direction. He rests in the shade for a bit and hydrates when the sun is at its harshest.
The young fellow is dehydrated. He's run over 12 km, he thinks he saw some of the mentioned clues, but he's not sure. He needs to get back to town to get a drink of water.
The afternoon sets in. The young fellow is covering a lot of ground, but is not rally getting anywhere. The graybeard, meanwhile, has found the little pond and the hollow trunk that holds the little treasure chest. It takes him some time to walk back to the finish line.
When doing anything, there is the experience and velocity aspect. If you're running fast but don't know which way is right, you will make many mistakes. Your speed will allow you to recover quickly. If you're experienced, you will likely plan better and your slower progress will be in a more correct direction.
What is better? I wish we could all be spry 90-year-old veterans with the speed and stamina of 18-year-olds. For most of us, it does not work that way. Different projects require different skills. More established companies don't want to risk key project on inexperienced talent. Young startups don't really know what is going to work, so making lots of mistakes and recovering quickly may be an advantage. It's getting the right mix of people for the job that is the key.
https://pages.18f.gov/joining-18f/ https://www.usds.gov/join https://usajobs.gov
Public sector work sometimes does, but lots of times has "or equivalent experience", and much more often than private sector work has clear and objective definitions of what is the "equivalent" alternative for particular purposes.
USDS sure doesn't act like it is desperately in need of good technical staff. Best I can tell is that they are desperately in need of people who can sell Agile to government suits.
I have no personal experience with USAJobs, but the experiences of the many people I know who have is that you are SOL if you don't have veterans preferences.
Having gone through that multiple times personally, veteran's preference is not a requirement.
Anyway, that advice at the end of the article is BS. Being older does not stop you from coding, and it does not stop you from being an engineer. Engineering is not age dependent, but practicing it as a job may be.
These days, re-inventing the wheel and blogging (writing books, speaking at events) about how you solved 'your' problems, are the new way.
There are many very intelligent younger people (as there have always been), but most of them, brought up on the shoulders of giant, are no longer interested in what those giants did and think they can fix the world on their own.
shrug
Now, I'm not a coder, except to the extent that every sysadmin is, and my field's definition of "output" is different (and for that matter ops in general is grayer than dev). But just personally I feel a confidence in my skills and experience that I didn't have even a decade ago at 30. And also I seem to have a longer attention span than I used to (9am HN commenting notwithstanding). I have a much better sense of how long an implementation will take, what its blockers might be, etc.
IOW I'm liking work at 40, at least personally.
The advantage of this is that gets you out of some of the myopia that the tech sector has a tendency to instill, as well as broadening your geographical opportunities beyond the few tech hot spots. It also teaches you the three most important words a sysadmin has to learn to say: "I don't know". A sysadmin who can't say that immediately when it's true is going to have problems (after all ops is about 85% reading documentation), and figuring out how to get data from a barn to a datacenter will teach you to say it quickly.
Another piece of advice: if you haven't already, work in a datacenter, at least once, for at least a year, before you quit in disgust (everybody does). No datacenter sysadmin is happy, but it's a huge resume buff and it teaches you a lot.
Why is that? What kind of valuable experiences are you thinking of?
The bulk of the problem is that the software field has been growing exponentially for a long time. If you double in size in 2 years, and the bulk of the new guys are actually new to the workforce (as seems to be the norm), then instead of a nice even distribution of ages, you'll end up with nearly half of your workforce less than 2 years out of school.
This isn't really a solvable problem, short of waiting for the size of the software industry to level out, and then waiting for the younguns to grow up.
I'm not saying that there's no discrimination -- I have no data -- but it's likely to be less rampant than this makes out.
If this isn't prejudice, I don't know what is. It's not, "40-plus women are employable if they are competent." It's that being a 40-plus woman is enough of a signal, people feel justified enough to "err on the side of false negative." Really, how many 40-plus women have most 20-somethings actually encountered as coders in the workplace? How many 40-plus women have most 20-somethings actually encountered as managers in the workplace? I suspect this prejudice comes from outside the workplace.
I'm not sure if this works in other fields. Probably in lots of niches.
Remember when graybeards were coveted for fellowship positions and authored the most important books? That was only fifteen years ago or so.
a) lack of mentors for younger generations;
b) repeating the same mistakes our generation made.
a) is bad. b) is worse.
a) and b) combined lead to fads in which one burns tremendous amounts of time figuring out what it is and how it works, only to become obsolete by the time one masters it.
Old people like me pick their technology very carefully, because they've already burned exorbitant amounts of time mastering all kinds of technology fads during their lifetime, only to find that most of them don't fix, or make the problems even worse.
In plain English: we reject 99% of the fads out there because we can tell from experience what will work and what won't, and what the challenges and pathologies will be if we deploy on that particular fad. We don't reject fads a priori just because it is something new, but on the very simple metric:
could it be as bulletproof as possible, so I don't get a call at two o' clock in the morning?
Yes: continue research. Attempt breakage. Re-evaluate based on the results of breakage.
No: reject.
Where we, the old people failed: I take on apprentices. Most of my peers do not. That is why we end up with, for example,
https://www.youtube.com/watch?v=Ms3EifxZopg
...where a few lines of AWK code would do. And my peers are nowadays almost embarrassed to even mention such robust technology, instead of actively teaching and promoting it:
http://dtrace.org/blogs/ahl/2016/08/02/i-love-go-i-hate-go/#...
this is where we failed: to teach. To take on apprentices. This is why humanity keeps repeating the same mistakes over and over again, and nowhere does that appear to be so acute as in information technology.
We can do better. Take on apprentices, and have them commit to teaching others once they themselves become masters.
I don't mean casual mentorship; I mean a formal apprenticeship. Yes, that means you Bryan, and you Adam. And you Jerry. And you Max. And you Robert. You know who you are.
This is an intriguing idea. But our culture doesn't offer much in the way of a framework for it. Will you expand upon what you mean by it, and how you've made it work for you and others?
I've also planned an apprenticeship program, where I had pupils formally assigned to me to mentor. I'd start them while they were still at the university doing their bachelors or masters. Usually they are new to UNIX, so the first thing I have them do is read the entire manual page for tcsh and zsh. Then move on to teaching them how to shell script, then how to program in AWK. Once they're past that, I move on to teaching them C.
For shell programming, I tutor them one on one, covering looping, input, syntax, interface design with getopts). I teach them why having ".sh", ".pl", ".py" or any other extension on an executable is a bad idea on UNIX, and there I cover what it actually means for a file to be executable on UNIX. I teach them about the runtime linker. I teach them about compiling and linking, about how functions map to symbols in an ELF executable. I teach them about ELF. About process spawning, context switching, high interrupt counts, 32- versus 64-bit code, instruction encoding. About what being a zombie process actually means, how they become such, how they get adopted by init(1M).
Eventually they hit deeper and deeper problems, so I inevitably end up teaching debugging and OS programming.
For teaching them how to program in AWK, I have them go through all the chapters and all the exercises in the Gray AWK book by Aho, Weinberger, and Kernighan. Then I help them with the actual real world problems they are attempting to solve with AWK, by showing them how to do it and explaining how it works. This is usually the time when I cover all the formal algorithms they're supposed to be learning at the university but aren't: stacks, queues, linked lists, doubly linked lists, sorting, pointers and pointer arithmetic, topological sorting.
For teaching them C, I have them go through the ANSI C programming language book, 2nd edition, and then cover anything that they don't understand with examples. Then I have them follow that up with the Advanced C programming by Example book. Then I cover dbx(1), gdb(1), and mdb(1) with them (what I know about mdb(1) anyway, and I touch upon kdb(1)). Throughout all of this, I cover cpp(1), make(1S), gmake(1), and m4, as well as lex(1) and yacc(1).
If I am forced by circumstance to teach them on GNU/Linux, I constantly and consistently pound it into my students' heads never to use GNU constructs or GNU specific features; by the time I'm done, they are able to write clean, portable programs in shell which work on any UNIX-like platform without any modification, and ditto for C programs. I purposely teach them to stay the hell away from bash(1), and use either the original Bourne or Korn shells to program.
If they are apprenticed to me for a long enough time, I will also cover complete UNIX system, network, and security administration (up to and including locking down the system and configuring the firewall and IPsec); by the time I cover the material, any of my students should be able to take on and pass a Solaris system administration exams and get certified. And with that knowledge and some shallow preparation, they can then easily ace the redhat Enterprise Linux certification exams.
Next, I cover SQL and database administration. Usually the places I work / consult at have Oracle, so I teach them how to administer an Oracle database, show them where the documentation can be found, and generally prepare them to take the Oracle database administration exam. If we have it, I will also cover PostgreSQL, and I cover SQLite. Finally, I show them all the bugs and all the issues in MySQL with a warning to stay the hell away from it and never use it for projects. By the time I'm done with them, they are comfortable taking on a database administrator's job or programming applications in PL/SQL inside of the Oracle database. And where there is Oracle, sooner or later, there is Automatic Storage Manager (ASM), so covering that inevitably leads to covering storage area network administration on the OS side, which ties into their UNIX administration I taught them earlier.
By the time I'm done with them, they are able to comfortably program applications in shell, AWK, or C, in addition to being able to administer UNIX systems and relational databases.
From that point on, they have enough knowledge to master pretty much anything in computer science.
“Younger people are just smarter.” - Mark
not wiser :D
My view is you need to be smart for the short-term solution / problem & unencumbered by obsolete boundaries / limit.
You need to be wise for the long-term stuff since it's human nature to repeat the same mistakes & not learning from it
p/s: I'm young
When I read statements like that I think, 'optimised' for the given problem(s) at hand. Problems change over time.
https://news.ycombinator.com/item?id=12503764
> the ability to build long term pattern recognition of technology business cycles, the "all is old is new again"
I don't really like the term "coding", because when I got started, a coder was pretty close to the bottom rung. You had Systems Analysts who wrote specifications, Programmers who turned those specs into flowcharts, Coders who translated the flowcharts into actual code on coding forms [1], Keypunch Operators who punched that code onto punch cards, and finally the true high priests, the Computer Operators who ran your batch jobs and gave you back the printouts.
At least that's what they told us the serious enterprise software companies did. In truth, we were a bunch of hackers who punched our own programs on Teletype machines.
Later I got into writing DOS applications and TSRs and custom BIOSes, and then Windows programming starting with version 1.0. Some application programming, some language design, and some systems hacking like figuring out how to hook into the Windows font rendering before they had scalable fonts, so I could render Adobe's Type 1 fonts behind Windows' back. Worked on Visual Basic and created the VBX interface.
10-15 years later, I switched to web app development and had a pretty good run with that. Helped develop jQuery and taught a lot of people how to use it, got into GIS and mapmaking, did a bunch of election results maps for Google.
Then a funny thing happened: I got into VR, and it turned out all my Windows experience was relevant again. I was talking with a VR startup today and the CEO said "I thought you were just a VR developer - but you've done all this Windows systems hacking too? Maybe you can help us!" (They are trying to do some tricky DirectX system integration.) And the VR work also gave me a chance to get up to speed on Android and iOS development.
They say to leave everything more than 10 years ago off your resume so people won't realize how old you are. But if I did that, this VR company wouldn't have noticed my Windows experience from back in the day. And if you meet me you'll figure out my age soon enough!
At this point I've programmed in about 40 languages and a bunch of different platforms. If you ask me what my greatest strength is, maybe it's that I'm comfortable jumping around all sorts of languages and OSes, and I can pretty much always figure out a way to hook them together.
But I envy people who have become world-class experts in one important thing. One friend is a data scientist who does everything in Python. Another is an iOS expert who knows everything there is to know about Objective-C and never wants to use another language.
So maybe jumping around so much is my great weakness too. When I talk with companies, they are often looking for someone who is the best at one particular thing. It may be data science, Android or iOS development, web front end, or whatever, but they want that one specialty. They may talk about "full stack" developers, but it tends to be a pretty specific "full" stack.
What is the most productive role for someone like me who has worked on so many different kinds of systems that I've lost count?
[1] To get a taste of the old days, search for https://www.google.com/search?q=fortran+coding+form and you'll find some FORTRAN coding forms like this one: http://org.coloradomesa.edu/~lpayne/fall%202014/CS1/coding%2... - print it on some 8.5x14 paper, sharpen your pencil, and start coding!
This thread has been mostly pessimistic, perhaps there is hope yet?
jQuery was one. Another was Visual Basic, the VBX, and being known at the time as a Famous Windows Programmer. Before that was my infamous Steve Jobs story:
https://news.ycombinator.com/item?id=7451018
Maybe this is one big advantage of youth: you can make mistakes like this and still have many years to correct them. At my age, well, I still do have plenty of good years ahead of me, but I certainly don't have as much room to "pivot" as I used to.
As a profession we have done ourselves an enormous disservice by letting outsiders label us "coders". If the journos that do it became known as "typists" they would explode with indignation.
At my first day at my first job at gamedev consulting company, around seven years ago, I've got PSP devkit with a task to port a game to PSP. Game was using an internal cross-platform framework that had some support for PSP. I learned on the job how to run and debug code on devkit. I had to extend framework's support for PSP. It was very satisfying project. Later on I also learned on the job some iOS and Android programming. I heard about a colleague that was sent to a client as a help in iOS project, when his first experience with iOS was a book that he was reading on the plane. It all worked, because people there were great generalists.
After a few companies and pause in mobile development (around 2 years) I applied for an iOS developer job in cool startup. The guy that was checking my competency was asking me many questions that I didn't knew answers to. But I could quite reliably imagine most probable answer and he was totally surprised that I could quickly get to the answers (even if my vocabulary was a bit off), by just thinking. I couldn't believe that someone in his position can be surprised by such things. Later on HR person was asking me why I want to be iOS developer if I don't even have a mac or iPhone. I described my previous experiences and that I didn't have PSP devkit or prototype set-top box (at other job) at home either, but it just did not compute for that person. In the end I didn't get the job, but after all this I wouldn't take it.
I think that for such cool new companies their stack is so advanced and so special that they cannot comprehend that some generalist can do the same as many of their specialists in no time. Maybe it is more generalist vs specialist than young vs old?
I've seen it suggested that if anybody lists 20 different programming languages on a resume, they're "obviously lying because it's impossible for any one person to have learned so many programming languages."
So what to do if you're in that case? aren't their companies out there that hire people for their skills?
If your management is moving towards stack ranking, you'll find a couple of us around, because we're like the expendables on _Star Trek_: we're easily discarded.
It is difficult to find career paths which continue to make it worthwhile and still continue coding, but it's also difficult to find people who want to continue coding and can keep up with the progress of technology. Further, it's difficult to evaluate whether someone has the right combination of skills, desire, and adaptability in the hiring process. Unfortunately, most people seem more likely to associate 2 out of 3 of those traits with youth, and those also happen to be the hardest traits to see on a resume. For example, if someone has worked on a lot of projects in a lot of different software environments with different programming languages, it can be difficult to determine whether this means they can adapt well to change, or they can't work well with a team or grasp the necessary concepts for a given platform or language.
My arrogant (or cueless, as you wish) self then smuggly told him "software is different. People don't care if you are a rolling hairball as long as you can write code".
He was right, of course.
I'm not sure with star programmers with hot properties such as yourself this will be an issue but then there is the pull quote from Gosling in the OP!
Today if a young engineer asks for my advice, I consistently tell them to either take the necessary steps to end up on the stakeholder side of tech, or to save like mad while the going is good to allow for the necessary career switch at mid 30s.
That appears to be one of the motivations for certain prominent voices in the industry dismissing the value of experience. To be fair, even in early 90s there were telltale ads for "senior engineer, 3 years of experience" :)) I used to laugh when I saw those back then but now the joke's on me.
> I'll probably switch to project management or something like that when I'll feel that it's the right moment
None of my business but why not build a business around Redis and tend to your garden in the warmer climes. Milan is charming in a way but it[']s the coldest (in the psychological/emotional sense) Italian city I have ever visited.
It's actually pretty true to my experience. I'd rather work with someone who's confident and self-assured, rather than emotionally needy. I'd rather work with someone who's experienced. I'd rather work with someone who's professional.
In short, I think I'd rather work with Tim …
How many people had access to computers 25 - 30 years ago? Very few, like me, and we were privileged. Getting time to learn with a computer was expensive like getting knowledge about programming them. For example computer APIs were on books you had to buy.
You also had to spend so much time fixing your computer's BSD(blue screen of death), making your (software)modem to work, or your Linux distribution to install when it was all from the command line.
Now everybody can buy a Raspi for 40 dollars and connect it to TV and it just works. Everybody can access top quality tutorials on youtube, all the APIs and other documentation is online.
People in Ghana, Kenya or India can share a Raspi computer and learn. Chinese could also start buying them. While the West access to tech privilege persist, the gap is narrower and narrower over time.
This means there are a hundred times more programmers than in the past, specially young people. If they can compete with you watching youtube channels, they will, obviously.
If you have certain age with only programming knowledge you are not privileged anymore. This is tough for some people to understand.
I remember when knowing HTML alone could earn you lots of bucks. Not happening anymore.
I think the following generally helps:-
* Keep your CV/resume impressive. Nothing says "unemployable" like 10 years running an outdated DB system at a boring company;
* Change job or interview frequently;
* Don't try to adopt all the latest fads (impossible, anyway) - instead, play to your strengths and focus on your general area of expertise, and every few years learn a new relevant language or system in depth;
* Keep those old-school skills sharp! You can always impress a 21-year-old hacker in a hoodie if your command line / regex / disassembly / wireshark (or tcpdump!) skills are better than his.
What does that even mean?
>Change job or interview frequently
It's hard for me to fathom that people see this as a positive. Red flag for me. But I guess I'm getting "old".
Be careful with that... being a job-hopper is probably worse than "10 years running an outdated DB system at a boring company".
Just look at the video game industry. Relies on a steady stream of suckers who can be used up and spit out. Their love of games is taken advantage of.
Many older workers are better, not worse, than their younger counterparts. They are discriminated against because they can't be so easily fooled (e.g. thinking a beer fridge is an acceptable trade for lots of unpaid overtime)
Experience matters. It took me years to even realize that programming is only half of my job. Though I'm not yet an OG, I'm a better engineer than when I started.
In my case, 36yo, in a startup, I'm the oldest in it. But I've been interviewing many people and I think we only got 1 candidate which was older than me (we didn't hire because it was not a good fit, with so much experience but without much experience in our tech stack, we thought it would mean paying a fair amount for someone to be basically learning from us, as we were looking for coders, not architects/principals/leads).
Even if there were legitimate reasons for not hiring that person (sounds like he/she was not a good fit for the position), the way you frame it sounds like you do not understand/appreciate what a senior engineer brings to the table. You don't pay seasoned professionals to come and learn the latest fad (though for them, it will look like a perk), you pay them to double check your ideas and spot potential problems they have seen before.
If you are offering a junior position with junior-level salary, and the senior candidate is OK with that, what's not to like? There are of course risks about the new hire jumping ship when something better comes, and you may structure their pay to discourage early attrittion. But if you blame the senior guy for not being junior enough, that's exactly the ageist attitude we are discussing here.
candidate, in singular: it was only one.
> you do not understand/appreciate what a senior engineer brings to the table. You don't pay seasoned professionals to come and learn the latest fad
I completely agree, but this particular candidate had been using JavaScript for the past year and when we asked him why did he switch to JavaScript from the other tech stack he was using before, he answered something along the lines of "well, it's the latest fad".
So believe when I tell you, we rejected him exactly because of the opposite reasons you state.