Somehow I can't equate myself to my age number, 46.
In 25 years there has never been a moment when I wasn't in love with learning the latest cutting edge tech.
Over the years it's been so much fun...
...to progress from the BBC B to pascal on the mac to pc's to unix boxes to c cgi scripts to perl to php to mySQL to flash actionscript to ruby to javascript to noSQL to node to socket.io to html5 css3 to iOS to android to rabbitmq to laravel.
...to move from crappy first gen-linux boxes serving web pages from my front room to using web hosting companies to the elastic cloud to puppet to salt-stack to containers.
And I'm only just getting started.
I can't wait to get in to VR, 3D printing, hard core signal processing and so much more.
When I'm screen sharing and problem solving with a 25 year old dev on a hardcore problem I feel no different in any way to the person on the other end of the line.
I've also been programming for 20+ years and it seems to me it's only getting better. To be fluent there really is a lot to learn that takes time. From learning how the whole operating system works on the lower level through all design patters and common pitfalls to mastering everyday tools (dvorak, zsh, vim etc.) that shorten the path between ideas and working code.
I know some coders in their 60s that just like you have a fresh mind and are still eager to learn new things.
I believe association with older people being less capable of mental task and creativity stems from how our society works (or rather worked). People used to do the same job, then become some grandpa with not much input or challenges to keep their brain active. It is quite well documented at this point[1] that when you keep challenging your brain there is not all that much degradation coming with age. It's just that as you get older it's becoming harder to present something really new to your brain - it will tend to view it through existing patterns and use shortcuts that you already have. That's why picking up some new language (not just programming lang) just for the sake of learning something new is a good idea (but what for? could be for fun - dopamine is a lot of fun)
This is fantastic, and makes me hopeful. I'm almost 40 and no real career accomplishments but there's still time for me, maybe, before I just decide to hang it up and just go home.
The article focuses on the fact that as programmers age past 30 their salaries grow but they have roughly the same skills. But that is not the main dynamic here. The main dynamic is that as a person's brain ages, it improves in some ways and gets worse in others. The improvement is that you have more depth and experience. The loss is that your brain gets slower and less flexible.
Unfortunately, in computer programming you will run out of experience and depth that you can accumulate after about 8-10 years of work (say ages 22 - 32). Every new technology is just a variant of the previous 999 technologies. But you still keep getting older every year, and incurring the downsides of getting older!
Compare this with, say, being a doctor. A doctor at 32 is just finishing residency, so he or she has just finished formal education. At 42, she has 10 years of experience, and a doctor with 10 years of experience is better than one fresh out of school. The doctor keeps getting better at 52 (20 years of experience) and 62 (30 years of experience).
The big picture is that computer programming is a field with low barriers to entry and where young people have a significant advantage. Staying in a field like that for the long run is going to lead to a brutish brutish existence.
There are many posts here along the lines of "I'm 39 and still doing ok". That's beside the point, because in the future you will be 49, then 57, then 65. Remember, Social Security full retirement age is 67.
It doesn't make sense to wait until you are 40 to switch. Every career field accepts young people easier than old people, which means that the time to start planning your switch is today.
> Unfortunately, in computer programming you will run out of experience and depth that you can accumulate after about 8-10 years of work (say ages 22 - 32). Every new technology is just a variant of the previous 999 technologies. But you still keep getting older every year, and incurring the downsides of getting older!
I'm going to call bullshit on that. There are a lot of recycled technologies (especially in web), but the notion that after 8 years you know all there is to know -- that's absurd.
I just turned 30. I work with people both older and younger than me, but I learn way more from the 40+ year old people in my office than I do from the 20 year olds.
Like the parent tried to explain, different fields (programming, law, medicine, etc) have different experience curves.
There is definitely enough in programming to learn for 200 years, if we lived that long. It's just that when programming in area E, a 47 yo who learned A, B, C, D, and E does not have an advantage over a 32 yo who learned B, D, and E. But the 32 yo has the advantage of his youth.
I also don't get all the "I'm 30 and I'm doing ok" statements. The article is about issues you'll experience when you're 45 .. 49 .. 55 .. 59 .. 63 .. etc.
Edit: let me do an easy computation for you. Time from age 22 to age 32 = 10 years. Time from age 22 to age 67 = 45 years. Big difference!
>It's just that when programming in area E, a 47 yo who learned A, B, C, D, and E does not have an advantage over a 32 yo who learned B, D, and E.
Then maybe task E is not the right task for the 47 year old? Maybe when building another accounting system it's enough to know all about accounting systems, but the closer you get to the cutting edge the more useful broad knowledge gets.
For example there is just about nobody with 5 years of experience in VR-technology, but if you have worked in a number of even slightly related fields in the last 20 years you probably can bring a lot to the table.
But one of them has 15 years more time to get experience in a number of fields (or in depth in one or two fields). I think 15 years is enough to still make a difference in this regard.
I understood his argument, despite what your condescending comment suggests, I just reject the premise it's built on. His premise is that in 8-10 years of experience you will be "max-level-programmer" and after that point there's not much worth learning, and you're a depreciating asset and you should parlay your experience into something else.
The ageism in the tech field should bother everyone, because you too are one day going to be old.
I didn't mean for my comment to be condescending - sorry about that.
I was a computer programmer from 20 to 21 (I worked full time in college), and I changed fields at 21. I am in my 30s now. I didn't figure out these dynamics by myself - I was fortunate that my manager at the time was also changing fields, and he explained these things to me. He was in his early 30s and he became a doctor.
Now I am just trying to return the favor by describing these things to younger people on HN. And I read HN for kicks. :)
I'm quite sure there's more to software engineering than can be learned in 8-10 years. I spent 7 years working with one tiny part of formal software verification, and still didn't get to the bottom of it. Perhaps it's true in web development, where it does really seem like the industry is
recycling ideas every 18 months. But there's far more depth to the field than just "JavaScript framework n+1" and "Yet another task running tool fundamentally identical to the previous 328, but written by a fashionable company".
The point is not that there is nothing to learn after 8-10 years. There is enough to learn for multiple lifetimes. The point is that after 8-10 years additional learning/experience will not give you a competitive advantage compared to younger programmers.
Also, I can see why someone would downvote my post above, since it describes an unpleasant reality. But I think it is crucial for young programmers to be aware of this dynamic!
You're getting down votes because it's simply not true. It's not about age it's about the person. And it couldn't be more wrong to say that there's nothing to learn after 8-10 years, even in web.
But let's talk about the competitive advantage part of your argument.
Personally, I have spent 20 years collapsing and simplifying "everything" in my work product. IE ui design, coding patterns, and all other aspects of my tech related work product.
Whenever I show my code to new devs they usually say "yup I get it, it's easy". But it's not easy, I just spent a crap load of time thinking about those patterns over the years making them easier and easier over every iteration.
So, that's one competitive advantage right there.
But another competitive advantage polyglot old guys have. They can truly be a full stack developers taking an idea from mockup to web and mobile and completely scaled distributed systems.
It's VERY hard for anyone to do that without putting in 10-15 years because each discipline (design, mockup, mobile, architecture, scaling, etc.) takes a lot of time and effort to master. That said I have met 30 year olds who started at 15 who could do that too.
I think of it like the CEO who worked his way up from the mail room, he's seen every part of the company inside and out and that's why he's so good at building companies now.
Look, I agree with your suggestions. But each of the things you suggest (improve yourself, become full stack, maintain mental elasticity) falls in the category "try harder". That only works with things you can control.
There are also things you cannot control - changes to your brain as you get older, the kinds of jobs that are available, what other computer programmers specialize in. These are your odds.
Your success is a function of your efforts and your odds. Success = f(try harder, your odds). Since you are human, you can choose your path, and it doesn't make sense to choose a path where the odds decline so dramatically as you get to 46 ... 58 ... 63 ...
Sure it does (at least, as much as any other "intellectual" field, like accounting or law). Do you want the guy who knows X (or 3 variants of X, each sequentially in fashion)? Or the guy who knows X, Y and Z?
The key is, no matter the age, to keep expanding your knowledge base.
Well, different intellectual fields have different experience curves.
Accounting, medicine, law all have much longer experience curves. Accounting also has significant barriers to entry (though not as high as medicine). Law has lower barriers to entry and you can see them facing a wave of unemployed lawyers and closing law schools right about now. Etc ...
> The big picture is that computer programming is a field with low barriers to entry and where young people have a significant advantage.
Computer programming isn't just one field, there're several completely different fields. All what you said might be true for the web development field, where the technology at hand isn't really that hard and you apply more or less the same technology and knowledge for each web project.
But there're several other fields where experience and knowledge are a lot harder to gain, and therefore also count a lot more, just look at the systems programming world or the more engineering heavy fields.
At my firm are a lot of >50 year old people, which are valued a lot for their knowledge, and our work isn't about getting shit done as fast as possible, but about getting something done right.
>>But there're several other fields where experience and knowledge are a lot harder to gain
Factor in internet that statement isn't true anymore. The amount of knowledge on the net today is mind boggling. Its scary to imagine how much information has become cheap and easy to access these days. And no one knows where this is all heading.
The jobs that require knowledge and experience hard to gain are already very few and shrinking with every coming day.
>>work isn't about getting shit done as fast as possible, but about getting something done right.
Wait until a 20 year old shows how it can be done fast and right.
I temporarily worked in safety-critical software development. There's a lot of tools in that domain that simply aren't as googlable(read: expensive) and cannot be learned online.
Often, in these sort of situations, the field isn't even that visible. I certainly didn't know how extensive it was until I worked in it.
>>Wait until a 20 year old shows how it can be done fast and right.
I will applaud the 20 year old who somehow manages to disrupt the safe software industry, but I doubt it will ever happen.
The internet makes information easily available, but it doesn't always provide context. For example Hadoop is great for big data, but I trust the fourty-something year old more than the twenty-something year old to know when to ignore the current trend product and use stream processing instead.
A few points come to mind. Are the 50 yo people really computer programmers, or are they managers / architects / scientists / etc?
The point is not that there is nothing to learn, but that after 8 - 10 years, additional learning/experience does not give you a competitive advantage compared to younger programmers.
Finally, you can always have exceptions, niches, etc. That does not change the dynamic for the field as a whole.
I know several older programmers 55+ who run rings around younger programms. They don't just write better code they also pick up new systems, languages, and techniques faster.
I suspect part of this simple selection bias where the best stick with programming for longer periods, but there is huge bennifits to really wide ranging backgrounds. Sure, many things become outdated, but the 4th time you see the same idea presented in a new way your just picking up syntax not a new way to think.
I think the main building block is to have mental elasticity and willingness to try new ideas and technology.
Also, you need to be willing to get over the hump. That part when you are looking at something like node or rabbitmq. You've read the intros 2-3 times and it still seems like crazy incomprehensible gobbledygook.
When I get to that place, I stop working on it, go out for a walk and just let my brain work through it in the background.
30 mins later i sit down at the computer and it starts to make sense.
The other HUGE trick is to hire someone on Airpair to chat with you about the new tech for 30-60 mins. Actually I just gave you the best advice. Do the airpair thing for any new tech you want to get into.
I don't really have advice, but I know there is a very large number of people in their 40s looking to change careers so probably there are many common pathways, internet discussion forums about different professions, etc.
Same for people in the 30s. For example, in the lower ranked medical schools in this country (US), there are many former programmers in their 30s, and they discuss things on boards like http://www.oldpremeds.org/phpBB3/
More options:
- Go solo. At 40 you should be experienced enough to handle up to mid-sized projects, alone and on a reasonable time-frame. Try to pick projects that your clients will actually use, with new features and support contracts you will have steady income for the long-term.
- Go startup. Stop thinking you need to come up with the next über-for-x. There are plenty of opportunities for small sass shops that cater locally and provide sufficient income for a micro successful business. At worst you'll be acquired.
- Go sidetrack. I read someone said every business is a software business. Start a different career/business and you'll be doing the IT needs yourself. That alone is a huge competitive advantage.
These options allow you to continue programming after 40 and you should! It is an urban myth that past 35 programmers are not as good b/c they get tired faster or make more mistakes? The truth is that 20-somethings can put up with very long hours b/c they have the time (mainly due to not having a wife and kids) while 40-somethings have the experience to go right to the answer. That's productive vs efficient. I like to use a soccer analogy: a young defender is good when he's fast because he can outrun the attacker, while an old and slow defender is better because he knows where to stand and wait for the attacker. Experience is gold.
I'm over 40 and I've always worked as a consultant. Until recently I was the sole developer on a site doing eight figures in revenue (now I'm team lead). Without being arrogant here, if my skills match but someone doesn't want my level of experience, it's not a good sign for the someone.
On the flip side, I would love to throw out all of the languages and frameworks I've been using for the past few years and learn entirely new tech. That's part of the point of being in this business!
If you're a startup and have a bias against us greybeards, you're only hurting yourself. We'll learn your framework-du-jour and tell you how it bears an uncanny resemblance to something that didn't work so well in the past. Or maybe we've never seen anything like it, in which case we'll be delighted to cast aside all that old crap.
I usually summarize this thusly: "I have already made the mistake you are about to make". It should be obvious the time savings would worth it to "rent" me. And I am months away from my 40th birthday.
It's funny you should say that. A few years ago, at a company whose name everyone here knows I, an old gray-hair, almost lost my full-time job for warning a VP that she was about to make a mistake I'd seen before. I honestly thought she was joking when she told me about the approach she was going to use to deal with a "hard deadline" of four months. I laughed along with her joke until, with a shock, we both realized that I was actually laughing at her actual plan. She became indignant and ended our meeting (just the two of us), getting me transferred for "not being supportive of the team" and trying, unsuccessfully, to get me fired.
She gave the job to her three dozen "supportive" young programmers, who ended up taking 28 months (!!) to get the "4-month" project finally working.
So, after all that, did she eventually apologize and tell me that, yes, she'd made the same mistake I told her I'd seen before with the same results for the same reason, and that she should have at least asked me more about it instead of throwing me out? Of course not. This is the real world. She never spoke to me again and never forgave me.
To be honest, I don't find it that surprising. Being laughed at is not something people take kindly to. Of all the possible ways of letting her know that you thought her plan sucked, that was the one that was doomed to fail right from the start.
It was a failure of communication. Even before analyzing why or what happened, a failure of communication is something that arises out of actions of both parties and even the prevailing culture of the team.
Nobody really likes it, but half of the "politicality" of management has to be set in place to allow people to communicate with others who may or may not suffer from a sensitive ego and the company hasn't had time to figure it out yet. On top of that, it's usually a judgement call and may be a poor idea to formalize into your process an escape hatch based on judgement.
So maybe the original mistake was from the manager who presented a sensitive idea without enough seriousness to induce a careful response. Or the op who was too quick to feel comfortable interpreting it as a joke in what turned out to be a serious meeting. Or the culture which enabled the terms of the meeting to be ambiguous to begin with.
Only after that can you get into things like speculation on the maturity of the manager. It's actually quite a high maturity bar to jump over to stomach being laughed at by an expert. Not saying you can't set that as a goal, but merely that you ought to think about what happens when you find yourself dealing with someone who hasn't met that expectation.
For sure. Don't be a dick is a pretty good strategy. However, I didn't get the impression that was his intent though: "I laughed along with her joke until, with a shock, we both realized that I was actually laughing at her actual plan".
Right. I was neither being "frank" nor intentionally laughing at her plan. She was smiling, and I thought she was kidding. I was smiling, and she apparently thought I was approving. Suddenly, we both realized we were wrong. Oops.
At that point, the damage was done. I tried to explain why her approach of changing N things simultaneously wasn't more efficient than changing N things sequentially because of the combinatorial explosion of interactions, but she wasn't technical enough to understand what I meant by that, which made her angrier, and when I suggested an approach that would give us a temporary "Plan B" just in case we "ended up a couple of weeks late", she declared me "unsupportive" and ended the meeting.
The interesting thing about engineers is that they have very little tolerance for these destructive social shenanigans. Courtesy and politeness are one thing, but ignoring such a flagrantly flawed plan goes beyond courtesy and into professional negligence.
When empirical thought is your bread and butter, as it is in the case of software developers, it's hard to see why you should have to acquiesce to the VP's ego. If one intentionally stays off the political tracks, there really is no reason they should have to play unreasonable political games. Workplaces would be much more efficient if we accepted, or at least heard, the advice of the people who get paid for their expertise, instead of cowering in fear that we may damage the ego of some fragile soul who ended up in management because they were not competent to do any real work directly.
YMMV, but what one perceives as 'unreasonable political games' is highly personality-dependent. Most people have some set of behaviors that they find appropriate in some situations but not in others. For instance, wearing sweatpants to a wedding is generally frowned upon, for reasons that have little to do with their ability to maintain the body at a reasonable operating temperature. You can wear them anyway, but then you get to face the social consequences of doing so.
It's true that workplaces would be a lot more efficient under the regime you describe. It's also true that if my aunt had a dick she'd be my uncle. I'm suggesting that it might be a good idea for engineers to do the same thing as everybody else in the world and try to figure out when to wear sweatpants.
This is not anywhere near as socially tone-deaf as "wearing sweatpants to a wedding" -- it's more like showing up in a tux when everyone else caught the note on the invite "ironic dress only, please wear trash". The situation the parent described was the presentation of a plan of complete absurdity, which he advised against after realizing it was serious.
I agree with you that developers would be well-served by making a stronger effort to play along with the superficial niceties of corporate politics, but like I said, this transcends that and gets into a professional duty to advise against. If the workplace is so corrupt that reasonable opposition to a blatantly silly implementation plan can only result in the correct subordinate getting shuffled around and possibly fired, it's a liability for professionals to continue employment there.
I am now convinced that an idiot in a management position is unable to raise himself above the level of idiocy he is in - by any means. By definition, he should have to _listen_ and _weigh_ the facts being reported to him, not only to filter out the hidden agendas, but to also see all the facets of reality. Doing this would automatically exclude him from the idiots group.
Unfortunately most of management ones will not tolerate unaligned lower ranks and are unable to utter the words "he may have a point" to themselves and regroup and refocus.
Instead they will do whatever is necessary to remove the opposition.
See the Challenger for recent high profile examples.
You made my day. I meant "for" but indeed time is relative. I was 11 at the time and Challenger event is "recent" to me even now. Maybe because I was into stars and rockets and a friend showed me a newspaper cut with Challenger launch a year before or so.
My reading is that he wasn't laughing at her plan intentionally. Her plan was so bad that he thought she was joking, and he tried to be polite by laughing at the VP's joke.
There's nothing wrong with him. As I wrote above, as the brain ages, you get more experience and depth and foresight. The problem is that the decisions that use these abilities don't belong to programmers - they belong to managers (in this case the VP).
This is one of the main recipes for perennial frustration - be an older programmer trying to act like a manager from the bottom of the hierarchy.
I try to always write minutes from meetings. Sometimes I also send them out. Other times I just store them somewhere that has 3rd party timestamps (dropbox or googledocs).
You should quit working for her.
Either transfer to another department or if it is not possible - transfer to another company.
There is almost no upside working anywhere near her. She would screw up every meaningful project and attach failure to professional reputations of everyone involved.
What was the approach she was trying to use to deal with a "hard deadline"?
I can't give away too much here, but we had bought some companies and had to change our Web stack to show that we ate our own newly acquired dog food. That part was unavoidable.
I just assumed we would make a gradual transition, replacing the two stack layers one at a time, and starting each of those replacements with new, non-strategic web apps (ex: a mailing list signup sheet for some small event), always getting things working before extending the rollout. We would get as many things working as possible by the "hard deadline", and our customers for these new products (who would be developers themselves and would know that these were new products for us) would understand that a gradual replacement of our old technologies was just good engineering, not a sign that our new products weren't good.
But she told me with a smile that we were going to replace all of our Web apps simultaneously with a matched set of replacements showcasing what could be done with our new products (one of which would require using a version so new it wasn't even feature frozen much less production-ready, to show off our coming features) and, as long as we were changing two critical layers of the stack simultaneously, we would change all the other layers, too, right down to the OS and hardware "and just do it right".
And I assumed I was just laughing with her--yeah, yeah, very funny--until we both suddenly realized what was actually happening.
(And, I don't work for her. I was transferred elsewhere, and she was eventually laid off.)
as you allude to in your final paragraph, the unfortunate reality is that unless you're specifically assigned the task (in this case, the VP was), it's not your role to dictate the plan or criticize it to the level you did. at most, you can make your observations known once. this sort of thing very rarely ends in termination or quitting, but usually a sort of political/social alienation which you describe.
in reality, your only two options are either quit, or be the VP. as a non-executive/manager, you don't run the show, end of story.
HAHA, what? yes they are. what you're saying is that the at successful companies, individual contributors never get upset at the direction/architecture/decisions the executives and project managers choose - okay buddy.
I absolutely agree. Over the years I've worked with many sharp guys that are 50+ and their experience always commands massive respect from me. People who dismiss the more experienced segment of the workforce are, to me, absolutely, inexcusably incapable of critical thought. If all one sees the glitz of the young guys at TechCrunch Disrupt and concludes that they're the only talented devs out there, I want nothing to do with that person in a professional capacity, to put it plainly.
A novice doesn't know what tools he need. An expert has mastered the tools he has been given. A master starts thinking about the tools he COULD have :)
The main problem with hiring grey beards, as you put it, is that a lot of them aren't amazing, but due to years, they have an authorative attitude and expect to be paid more than your 20 something devs. If it's my money, I'd hire the 20 year old with gaping holes in their knowledge who are willing and eager to learn over the 40s something dev who thinks their way is better because they're 10 years my senior. I have a lot of anecdotal experience where I've rejected folks who were lacking a basic understanding of the pro's and con's of something. These guys aren't rejected because they don't understand the subject, but because they fail to accept there are scenarios where doing something the other way is better, or that at the very least, things at a bit give and take. This, I postulate, is generally because these guys have 10 years of 1 years experience, rather than the experience they're trying to sell themselves as having. These are the type of guys who will struggle when they're older. That said, when it comes down to it, most of the guys I try to hire are older than me. Age isn't a deciding factor, they just tend to be better.
Something that really frustrates me is people who are more expert than me but can't justify their pronouncements. I had a high school friend who I'm sure was smarter than me claim, "No one does object oriented programming the right way [except him]," but when pressed would just deliberately play games and mystify. Most DBAs I've worked with had their preferred way of doing things, but were incapable of answering Why? It's not easy working with these people. I've come to really value a colleague who can teach---that is, who can explain why they choose what they do.
I'd say anecdotally 2 out of 5 times I've encountered this it's been someone covering up for their own lack of understanding. These are the worst and the most inflexible. All but one DBA I've worked with was this way. It's the natural result of cargo-culting.
2 out of 5 times it's because the person doesn't have patience to explain all the background you'd need to understand, or they don't trust that you have sufficient background. Sysadmins do this all the time. If you're smart and already pretty familiar with their field, it's very frustrating. This isn't as bad as the former case, but it indicates personnel conflict and lack of trust. It's understandable though, e.g. answering technical questions for business people. I've gotten pretty skilled at giving non-jargony, intelligible, short, "popularizing" answers, that also invite further questions if desired. But it's not easy.
And 1 out of 5 it's because people with experience have forgotten the reasons. I've been there too. Just the other week on a Rails project someone wanted to use an ActiveRecord default_scope of "where deleted_at is null", and I had felt the pain of that on past projects, but it took a while to dredge up the details from my memory.
Most of the above reasons don't correlate with age/experience, but the last one does. Experienced people have so internalized certain lessons that they've forgotten the reasons behind them. You could say this is a bit like Michael Polanyi's "tacit knowledge". In this case, hopefully they still have mental flexibility to recognize that nothing is 100%, and if you give them time to remember and communicate their reasons, you can have a reasoned discussion and make a good decision. But recognize that making people think in this way often "feels like work." You are asking them to exert themselves, so it's important to communicate in a way that isn't challenging their knowledge but asking them to share it more deeply.
This is a great point. I try to get people to argue stuff on technical merits, and it's surprisingly hard to do. An example I work with now is the guy who bad mouths sql, non stop, and also promotes nosql non stop. He can't compare and contrast the two, even in general terms. Makes it impossible to have a discussion with him.
I try to be conginizant of where my biases are, and be able to support my assertions on technical grouds. When you do tht though, you often times see there are indeed many valid ways to do things.
That's actually a cracking point. I want to work with people who can defend their positions. The reasoning behind our decisions should be clear, if it isn't, you lose points against the guys who can do it. Luckily, age typically makes you better at this, which is what makes it really suspect when you get an older guy pulling an appeal to authority.
"with gaping holes in their knowledge who are willing and eager to learn"
If you don't mind the 'learning' involving data loss, security breaches and competitive disadvantages... sure. Go for it.
I say this as someone who did learning 20+ years ago, and have lost data, had security issues, and had many of the issues that come with learning technology (and business). My employers and clients absorbed part of those learning costs. But make no mistake about it, we all paid a price for those mistakes. You also will pay something extra for hiring those who are "willing and eager to learn" - it's just the nature of the beast.
Thinking that price is the only factor, and that maybe someone will take "a bit longer" to get something done is naive.
"I've rejected folks who were lacking a basic understanding of the pro's and con's of something...This, I postulate, is generally because these guys have 10 years of 1 years experience".
Did you bother to be honest with them about why you "rejected" these folks?
I'm one of those "40 somethings" who don't always think "my way" is better, but I can generally tell you why "your way" is crap, what it'll cost in the short and long term, and what the less crappy options are. I don't generally have a single "my way" because rarely does one approach fit even most problems well.
Hi there, you seem a tad upset. You should probably note my last sentence where I point out most of the better folks who I want to work with are older. My point was that simply being older doesn't make someone better, and that I'd rather train a junior than deal with a stubborn incompetent senior team mate. Unless you think the latter applies to you, you probably shouldn't be upset, I'm not generlising, I'm pointing out that if you're good, you don't need to worry.
That said, the assumption that you know better than me because you're 10 years older is part of the folly of what I'm pointing out. Indeed, you may know more than I do in my area of expertise, however you should base that on fact and merit. You should not assume that's the case just because you're older than me. If you tried that in an interview with me, indeed, it wouldn't last long and as a blunt Scottish guy, you'd certainly know why.
"and that I'd rather train a junior than deal with a stubborn incompetent senior team mate"
I was pointing out that the 'junior' often has more hidden costs than people realize. If you really are training someone - that's great, but I see far too little of that, and often just a hiring of the younger person either because they're perceived as cheaper, or a fear that the older person won't be a 'team player' (sometimes meaning "won't rollover and do whatever we say, work overtime, etc").
I'm not upset at you.
"I'm pointing out that if you're good, you don't need to worry."
Hrm... you still need to worry some, because you still need the other parties to be able to recognize that you're good (and to do that you need to be able to identify folks who are savvy enough to do that, ad infinitum). I've seen a lot of good folks get passed over for flashier/trendier folks who end up wasting lots of time/money.
The one other thing that comes with age more is a different perspective on time - it goes much faster than it did before, and watching people squander resources is... sometimes difficult.
It's actually not a case of fearing there are people who are difficult to deal with,
I have absolutly no doubt you've experienced people who are stuck in their ways have as many hidden costs as the junior.
I've taken over from older devs who don't use version control, nor a dev environment, refuse to use frameworks or follow coding standards.
Should we honestly believe they don't have hidden costs? Would you really rather deal with them than train a kid?
Either way, I'm only trying to counter the "old is good". I fully accept there are amazing older IT workers, just not that older is always better.
Did you grow the site into 8 figures or brought on board? What was the site doing? I would imagine management would be terrified of reliance on one, bus-getting-hit-by developer.
You'd be surprised how cheap or short sighted managers can sometimes be. I guess from their point of view they might see a developer as overly expensive and dogmatic.
I've seen companies with 7-8 figures and reliant on just 3-4 devs with unique and non overlapping abilities. It's more common than you think!
I developed the site entirely. To be clear: The site is essentially the interface to the business. I won't say I developed it "myself," since I was in a team with non-technical people who knew what functions they wanted from the site. However I was the only technical person involved.
Now we have more developers, for which I am very thankful. Unfortunately, way too much knowledge is locked up in me, and I never have time to commit that knowledge to bits, paper, or oral history.
Believe me, buses and beer trucks have been discussed as possible ends to my consulting gig. It is my fondest hope that this business has key-man insurance on me. I'd be pleased to know that they have such insurance, but less interested in knowing how much the policy is for!
Having worked with Ruby on Rails in the past and with Play2 and Scala currently, I think I can answer that.
For your regular web app, both frameworks are mostly the same, both are boring - Rails is more productive for very common tasks, but Play2 is safer because of the underlying language (well, if you pick Scala, otherwise Java just stays in your way). Things get more interesting in Play2 when scalability or latency starts to matter.
That's when you discover that Play2's architecture is entirely asynchronous and that Play2 supports asynchronous responses and web sockets natively. It does so by means of futures [1], actors [2] and iteratees [3] (also being migrated to reactive streams [4]).
Of course, the easy route with Play2 would be with Java, however I recommend that you pick up Scala. By doing so you're going to get exposed to concepts from functional programming in a language sitting on a platform that's very much practical for real world use. There's also this book on functional programming in Scala that's amongst the best books written on the subject [5]. Functional programming changes the way you think and it's all about sanity, functional code being easier to test, being easier to parallelize and being much less prone to accidental bugs.
But while you're at it also consider learning Haskell, probably the best functional programming language available, because even if you're not using it, it's currently the lingua franca for FP concepts, so when reading papers and blog articles on interesting design patterns related to FP, most of them are described in Haskell. It also spoils you with its incredible type system, so a language like Scala will become the minimum that you'll tolerate, working in Java, C#, Python or Go becoming unbearable ;-) A really good beginners course is this one from edX [6]. And then go learn Clojure, because it's a really practical LISP that is also oriented towards FP, except that FP in a LISP is really different from FP in static languages like Haskell or Scala.
And you know, the best thing about this path is that you're not going to learn just a framework, or yet another language, but you're going to learn about functional programming, which is a concept that transcends programming languages with its related mentality and design patterns and is useful no matter what you're doing and in what language.
But then going back to Scala and Play2, well that's useful right now too. And did you know that Scala compiles to Javascript too and it's awesome?
In all honesty, I'd recommend the use of Erlang alongside a framework like Chicago Boss, N2O or Nitrogen over Play if you want the actor model concurrency, default asynchronicity and WebSocket support. It simply supports these ideas in a way that Scala cannot compete with, alongside its concurrent error handling, the OTP framework, location transparent distributed nodes out of the box, binary pattern matching and so forth. Issues of typing aside (success typing is still impressive), it is a much cleaner and more FP-focused language than Scala's chimera paradigm.
The actor model for concurrency is rather poor depending on use-case. I prefer to mix and match approaches. I mean, modeling concurrent state machines, with bi-directional asynchronous communication that makes you easily lose sight of how data moves in your architecture, what could possibly go wrong?
And yes, it's a pretty good model for concurrency, however I consider it to be a compromise on the way to finding better approaches. And in the meantime, it just feels wrong to use a language that forces this mentality on you, unless you have specific use-cases for which this model fits perfectly that is.
And also, on the FP side - many people say that Scala is less FP than other languages, like Erlang. That's a rather odd assertion, because my experience has been the opposite. But that's for another discussion.
Write a trivial app in both. Use your own judgment to determine the best tool for the job. It is entirely possible that the best tool will be neither of these!
The website in question is written in Ruby on Rails. Since v1.0 (and Ruby 1.8). And it is now on current Rails (and Ruby!). Rails is a moving target, to put it mildly.
If I had to render an opinion, I'd say I love Ruby. Rails I tolerate. Some parts of Rails are great; others are tedious. By its own admission, Rails is opinionated software. You may or may not share its opinions.
As someone who has been 'solo' for a very long time, I have to heavily disagree with this opinion. Going solo isn't as simple or easy as what the OP seems to be implying. Going solo means you are essentially working two jobs at once as it takes a tremendous amount of work and dedication to network, find good projects and keep them rolling in to pay your bills. To further exacerbate things, each year the amount of competition that you face ramps up drastically as more and more workers enter the consulting world who are unable to price themselves correctly and are willing to work for less and less.
Furthermore, by going solo, you are now assuming 100% of the risk as to whether or not your new consulting business sinks or swims. Chances are, just like any start up, you will sink. Additionally, you will have added burdens such as insurance requirements, self-employment taxes, various state/county-level taxes (such as gross receipts taxes) and a laundry list of day-to-day operations that you will need to perform that aren't related to software development.
Going solo really isn't for most people and I wish we'd all stop perpetuating this myth that it is somehow easily attainable. Remember, a solo consulting business is the easiest business you can start, maintaining one is the most difficult business you can run.
> Go solo. At 40 you should be experienced enough to handle up to mid-sized projects, alone and on a reasonable time-frame. Try to pick projects that your clients will actually use,
I presume a troll? At 25 I graduated as MSc (physics), had not worked a day in the industry, and began my PhD studies. At 26 I figured computer graphics where much more fun than running quantum physical simulations in a lonely cellar and began my software engineering career. At which point I was still pretty clueless of the complexities of software engineering in the industry.
The time limit is not age but how much experience one has doing software engineering projects. One needs several unders ones belt, preferably some that have actually shipped so that one sees what the end user implications of the said products are. How long this will take? A couple of years? Hard to say.
>I presume a troll? At 25 I graduated as MSc (physics), had not worked a day in the industry, and began my PhD studies. At 26 I figured computer graphics where much more fun than running quantum physical simulations in a lonely cellar and began my software engineering career. At which point I was still pretty clueless of the complexities of software engineering in the industry.
How did it work out for you? I am curious as I am thinking of shifting from fin. applied math (econometrics) to SE ...
For me it worked pretty fine careerwise (I'm now 35 to be precise). I'm working now in the technology development department of a multi-discipline CAD vendor, everyone else is really talented and I mostly enjoy my tasks. I even get to write simple linear algebra like a QR decomposition now an then. The job is stable, mentally stimulating and my co-workers are sensible human beings - who are mostly way past their 30s and some over 50s.
I turned to software engineering because computer graphics gave and give me such a huge kick. I don't know what intrinsically motivates you so I cannot comment whether I would suggest the career for you or not. Here's the rub: software engineering can be viewed in some circles as blue-collar work, which means the work environments can vary quite a lot. Also, the discipline is really young, and it shows in the amount of cargo cult and bullshit quotes one finds peddled as "best practices". There can be gigs where co-workers are experts and those can be great, however, there can be lot of environments where co-workers are perpetual expert beginners and those can suck big-time (or so I've heard).
Realistically, software engineering is still a pretty solid career choice so from a sustenance point of view I'm sure there are far worse options one can choose.
If you graduate at 21 and start working immediately, by the time you're 25 you'll have 4 years of experience with a few shipped mid-size projects under your belt. It's not that uncommon.
The problem with age is you become less flexible. If your have a business where you know what you will be doing in 6 months time then experience is great - when your plans change weekly then the flexibility of youth is what you want.
Age makes employees less flexible in some senses like not being willing to put up with some of the crap that younger people will (60 hour weeks, endless crunches, etc.) I once did, but will no longer tolerate that crap from an employer.
But being older doesn't mean you stop learning, adapting to change, or lose the ability to deal with moving targets. I'm hopping rapidly between roles and widely varied tasks at my current gig better than I would have in my 20s or 30s since I've got more perspective and experience.
A more mature person might point out that if your plans change weekly you likely have a systemic problem, though, and would be more likely to point out the breakage.
>Age makes employees less flexible in some senses like not being willing to put up with some of the crap that younger people will (60 hour weeks, endless crunches, etc.)
This stuff is a false economy anyhow since it inevitably leads to a massive ramp up in technical debt even with the very best programmers.
I am not a young developer, yet I recognise what it is about youth that is attractive to employers. This is reality and I don't think there is anything to gained by pretending otherwise.
I am not suggesting that you don't have a problem if your plans change weekly, but unfortunately this is the way many businesses are run. When you have a very fluid workflow youth is very attractive.
It is not a matter of planning, but of adapting to change. I have worked in environments where change occurred regularly (outside forces at work) and I saw it was the young who coped with this change best.
I would need a concrete example but I'm not buying your assertion. Some of the most flexible people I know are all developers, irrespective of age. If you told me that older developers were more likely to ask questions and seek evidence before making a change I'd believe that. I find that most people confuse easy adaptation to change with pliability due to lack of experience.
I've seen the exact opposite. Startup, pivoted 3x in 3 years. The younger devs have a much harder time accepting he pivot and figuring out how to adapt. So without any more substantive evidence, my experience definitely refutes this silly argument that youth is more flexible.
Inflexibility is in my experience more often associated with a person than with their age. I've seen 30 year old devs that were absolutely incapable of changing over to new tech as it became available and I've seen 55+ people dig in with gusto. It's a mentality thing. Sure, mentality can change over time, maybe someone that's older is going to give something new a little while longer before hopping on the bandwagon or maybe they've already seen something similar fail in the past which is why they might be reluctant.
But flexibility is a hard-to-measure parameter to begin with and you need to know the people and their reasons before you can make call about it rather than simply their age.
I'd say more generally, as someone in their early 30s, that my experience says that if you're changing the plan weekly, the problem isn't with the employee, flexible or not.
In general, if the plan is changing every week, that probably means that the work I did last week was mostly pointless. That's a great way to burn someone out.
Good news though! I do contract work, and if you insist on changing the plan every week, you won't need to worry about whether I'm flexible or inflexible. I'll happily fire a client who can't make up their mind and thinks that the best path is to change direction every week.
Define "less flexible", someone doing consulting has flexibility to pick and choose clients. Someone who continually learns is capable of picking and choosing technologies. I would think even someone in their twenties would have issues with "plans changing weekly".
I've known people with nest eggs happy to take cuts for something interesting.
But I also know with experience comes a skeptical eye for being asked to carry extra load for less upside (yet same or more risk).
A story from some time back told to me. Founders had a UI, an algorithm, and an idea. It had merit. They sought someone out to build and run the actual service. The funding was angel, the role was senior to C-level, but the salary offered was 40-60k cut for a senior engineer at the usual suspects, equity capped at 4% assuming a trade off in salary.
Risk and reward to build out infrastructure and productize someone's idea? I could certainly get a couple of people to build it out in a "get us to a-round funding" in those guidelines, maybe even beyond. But as expectations on a non-founding senior/early member, one would assume way too much risk for the potential upside.
It isn't non-technical founder seeking technical co-founder waters, but damn close.
> The problem with age is you become less flexible.
For those who use their minds, which should be common in this field, those effects become noticeable much later in life. For most of the working lifespan the dominant effect will be an increase in experience.
Lets see every 20-30 year old we have brought in the past 3 years:
A) Is so arrogant they think they know it all. Then when they turn in the code it's barely passable and it become clear they are going to be difficult to work with.
B) Are overly emotional and they all take things way too seriously.
Now every 35+ person we have brought in for a project is:
A) Professional. Gets the job done and very well.
B) Sees the bigger picture and goes with the flow.
That's my personal experience but hey if I was management I would go with the 20 year old's all day long. As long as I did not know what they did or had to deal with them...Oh wait....
When I was a programmer in my 20s, I saw the same among my peers and tried to emulate an engineer in my 30s. I stayed mature, tried to focus on the big picture and was always open to advice from elders because I didn't know squat yet and was aware of it.
Just by doing that I excelled in many areas, and now as a n almost 40 year old developer I try to hire people who act like I did, and believe me they're out there.
When I was in my early 20s, did consulting stints while in grad school. One of my jobs, the senior engineer was a former Bell Labs white beard (literally) with his first 'program' hanging on his office wall :)
I remember most of my age group had enormous respect for the older engineers. But then, we didn't have Google and Wikipedia and entirely too facile access to information that lends the patina of 'knowledge' that is so easily obtained these days. So a lot of the aggressive posturing these days is really a symptom of the not knowing that you don't know that much yet ..
This is exactly why I enjoy reading HN.
As a 21 year old software developer, I do not understand how can someone be arrogant, just opening github makes me acknowledge what I still need to learn.
I've seen some extremely capable young people, really, it was absolutely incredible how far ahead of their age group they were.
Once you seen enough people you realize the bell curve always seems to apply, the curve shifts right along the experience axis over time but it will always be there and there will always be outliers. Don't rule out the 20 year olds just because of their age either.
"B) Are overly emotional and they all take things way too seriously."
This can be a positive. My experience with 40+ year olds is that they tend to sacrifice user experience/security for what they know. "Our customers won't care if they have to use Internet Explorer with ActiveX as long as it gets the job done." My point is that an experienced programmer who is not up to date can be as detrimental an arrogant 20 year old. The 40+ year old programmer who stay up to date though... They are worth their weight in gold and I aspire to join them one day.
Edit: Background - Got really pissed off at a 40+ dev using active x to launch external programs and making it a requirement that our end users use IE with ActiveX enabled. Almost lost my job because management sided with the person who had more experience.
"My experience with 40+ year olds is that they tend to sacrifice user experience/security for what they know."
I'm sure there are some people who don't expand, though I am in my 40s and am constantly pressing for the best UX possible for customers. I've suffered enough with bad UX, I won't go along with inflicting that on anyone no matter how challenging it might be to fix. On the other hand I am (almost) always grateful for people pointing out bugs in things I write now, but used to be a lot more insecure about it. A hit to the pride is nothing compared to the pain of shipping something broken.
"A hit to the pride is nothing compared to the pain of shipping something broken."
Well said. This should be the golden rule of development. I feel that too often we (both young and old) don't ask questions because we fear the repercussions of appearing ignorant.
Depending on what industry you're in, it's quite possible that your users won't care if they have to use Internet Explorer with ActiveX. A number of older and slower-to-change industries still require IE6 on corporate computers; supporting anything other than that is counterproductive, because their employers' IT departments won't permit them to load other browsers anyway.
I can't know if you're in one of these industries, but one of the virtues of experience is knowing when something isn't important because you know facts about your particular niche that an outsider wouldn't.
That makes it far, far more likely that they're stuck on IE6. Last time I went to the doctor's office, I saw a lot of very old Windows machines. You may wish that the world was a certain way (and frankly, I do too), but that won't actually make the world a certain way.
If you want to win this technical battle, your best bet is to say "I'll implement it in ActiveX if you really believe it is necessary for the business. However, Microsoft ended support for WinXP and IE6 in 2014. They have been actively campaigning to get their customers off of it. There are A, B, and C startups out there with competitive offerings that work on the iPad. iPad market share among healthcare organizations has gone up from X to Y% in the last 3 years, while IE6 market share has declined from Z to W%. If we implement this software as an ActiveX control, we will lose out on $M in sales, with the worst-case scenario being that our userbase upgrades from IE6 and we find ourselves out of business with zero market. It's happening already, as you saw from the market share numbers I just shared with you."
Basically, put the fear of going out of business into your management chain, with the data to back it up. (And if you can't find that data - then your management is right, and you shouldn't bother upgrading.) That goes over a lot better than "I read you should never use IE6 for HIPAA data on the Internet."
True, but to be fair I did praise the 40+ year olds who stay up to date and know their stuff. Just slightly jaded due to the ageism at my current job and lack of fact checking by management.
Software is a tricky balance between practicality and ideals.
In this example, the older programmer may figure he can meet the real requirements faster and with less risk using technologies he's already familiar with. He might be right!
Unfortunately, there's also a good chance he's being lazy, or political, or etc.
Try to give it a really good objective look to see for yourself which one it is. If the latter, you can try to influence the developer in an ego-friendly way or consider leaving if it becomes unbearable. If your managers have no real technical experience themselves then they are useless in these situations.
Good chance it won't be the last time you have to deal with this sort of thing. (coming from an old-ish dev)
Other 'sticks with what they know to a detriment' are devs that stick with SCMs such as svn or cvs or even rcs when things like git or mercurial are out there.
Younger devs who do have experience with this stuck in their ways behaviors and it can be frustrating and they try to side step it by not engaging the older devs.
Other 'sticks with what they know to a detriment' are devs that stick with SCMs such as svn or cvs or even rcs when things like git or mercurial are out there.
Don't mistake not buying the hype for sticking with something just because you know it. While there aren't a lot of reasons to favour RCS or CVS when Subversion exists, there are sensible reasons you might favour SVN over a DVCS for some projects.
It's been 10 years since git has been released, and in my personal case when this happened, there wasn't any good reason other than 'it's what I know'. The company started with SVN when git had been around for a while.
It's slowed down the company globally, prevents us from using various tools that don't have svn compatibility (like android's repo, gerrit or git's client side pre-commit hooks) and overall just been a relative pain the ass compared to git.
The very small edge cases that svn might be better at now did not apply to us. Notice I didn't say perforce, or google's custom solution in my example.
There are certainly good things about DVCSes like Git or Mercurial that you miss when using SVN.
On the other hand, every project I've ever worked on that has used Git still had some sort of centralised repository that was considered authoritative for controlled release purposes. The smart projects had a local server for this that everyone pushed to. The over-enthusiastic used GitHub, and in at least one case then found themselves unable to deploy when their systems were all up but GitHub was down.
Within that master repository, having a single linear history so you can identify exactly which code you've got in any given release with just a revision number is often helpful. In Git you simply don't have this, so you have to manually tag everything you might ever want to reproduce, which is basically everything on your master server, which requires extra hassle and clutters your log.
A separate but very practical issue is that SVN has worked fine on Windows for years. Git's support for Windows is getting better, but still far from ideal even today.
The sheer complexity of Git, up to and including data loss bugs because even Git's own scripts didn't track everything properly, is another recurring concern.
I've seen more than one very experienced developer, well aware of the pros and cons of different tools, argue for using SVN on a new project for these reasons alone.
I think that there's a huge variation among developers regardless of age or experience. There are people who are 25 and believe they've seen it all, and there are 45 year olds who tell you they've seen it all. What they have in common is that they don't listen to your advise and refuse to learn new things.
What they have in common is that they don't listen to your advise and refuse to learn new things.
I was on a job interview a few days ago and was asked "What do you dislike the most about working with others on a team" and gave them your exact answer, thinking it sensible giving the state of software dev nowadays.
I could tell immediately that they didn't care for it one bit, and the interview ended a few minutes later. I don't really know what they wanted to hear, but that sure was not it.
B) Are overly emotional and they all take things way too seriously.
I've noticed that some young devs have really, really hard time when we discover bugs in "their baby". This most likely relates to the underlying arrogance ("there cannot be anything wrong with my code").
I hope that all the future gigs I end up, I'm part of the effort to create professional environment where the younger devs can pick-up professionalism from the seniors.
But to be fair on myself and others, I was expecting something more intellectually challenging than what basically amounts to a job in 'abstract plumbing'.
Now I have come to terms with this reality life is much simpler.
I don't know a single software dev over 40 who isn't employed, and I know many that age. None of them had to change fields. Some are managers, but most are "senior" devs. Many of these guys have been programming internet technologies since the later 90's.
It seems in the places I've lived (LA, DC) the salaries are pretty squashed together after 5 years experience. Basically anyone with that experience is getting a similar pay check +/- 15%. For many after 28 you are close to being maxed on your pay which would put you in the same spot this article plops the 40 year olds.
I'm approaching 50, am employed, though I've found that the job search is a bit harder now-- particularly with bay area startups I saw a %100 correlation: If the interview as on video (eg: they could see the white in my beard) I didn't get a second interview. If by phone (no video) I'd get offers.
Also, last year in Austin I made exactly %20 more than I did in Seattle in 2000. Kinda sad-- up %20 in 15 years-- that doesn't even cover the inflation over that time period. (and I was making more than everyone else there, including some senior people.)
I've decided I need to switch to management, as it's time. In fact it's past time, but I have found that too many companies-- particularly startups-- don't promote managers from engineers, they want "biz guys" who don't understand software to be the "managers" way too often. (at least outside of silly valley.)
there was a news once about a 40/50 y.o. guy ( I think he was from UK ) who couldn't get a job as a manager in US because he was semi-bald. So he shaved his head entirely and found a good position in a flash. I need to find the link , this was an interesting story.
Look is important,unfortunately, but it isn't always about age, sometimes you're too fat, or not white enough ...
I remember that story, it was on the front page of HN back in 2012. The guy shaved his head, did a fashion makeover, bought the latest iPhone or whatever, and then on top of that had eyelid surgery with the goal of making his appearance more youthful:
Thought about that, but found a situation before trying it. I think I will do that next time... which is kinda sad, cause really, my experience makes me really valuable.
But in the end, would you really want to go work for a shop like that? If they don't want you based on the color of your beard, then I wonder what "other" surprises lurk around the corner..
I'm in my mid-thirties, so please take that into an account. Also I know that these are the questions that I have to ponder in the coming years, so your insights are highly valued.
pay squash is why you should get out of field. engineering is the new proletariat, working at companies that rake in millions for pennies, while all managers above you get twice your pay just by organizing your time.
Engineering is certainly not a proletariat. Engineers make more money than most professions and have more interesting jobs as well as lots of respect from other professions (I am not an engineer and I can tell you lots of people admire engineers). Also, many professions experience "pay squash".
It's a myth that most managers make much more than programmers and that they "just" organize your time. Let's have a little bit of respect, not just for our own professions, but also for the people we work with.
not when compared to all other profession that require a degree, constant lerning and are higly specialized (each enginering branch is not interchangeable, as well as within the same branch specializing in one area reduces your employment prospects in others)
also, the majority of managers are not the one that are in charge, taking decisions, managing risks and settings directions; middle managers types are way more common. and I do respect those of them that work well, but they are so hard to find that I'll stand by the 'most' in 'just organize things'.
What professions would those be? Law and medicine are probably the two most people are thinking of.
Law does pay more for very successful people, but at the median it actually pays less.
Doctors do get paid more, but they also spend a much longer time in training. The amount of time that most engineers spend in training is more in line with the amount of time that PAs spend in training.
>"It's a myth that most managers make much more than programmers and that they "just" organize your time."
Well, instead of just saying it's a myth and relying on averaged stats in the industry to satiate peoples' curiosity/jealousy, perhaps we should just all be more open about how much we all make. I.e. let's not make it taboo and "contractually-breaking" to discuss salaries openly.
I know, yes, our current employment culture won't easily handle the strain of all coworkers knowing each others' and their superiors' salaries. But I have noticed the trend reversing slowly.
I suspect that sharing salary info will result in a gradual downward grind in salaries, as people are offended by seeing someone make what seems like big money for easy work. This has been the case with public school teacher salaries.
I also think that salary data, with no corresponding ability data, will be meaningless.
I don't see the managers above really making that much more. In fact I made less when I was team manager than half my team when I worked for a big public corp. The C level does make a lot more and/or the owners do but not all the management in between. With tech knowledge, though, you can escape the squash by starting your own business fairly easily. Not necessarily easy to create a successful business but easy to give it a shot.
Yes, I believe this is more a more accurate assessment. I bet at most large and medium-sized tech companies, there's not a huge difference in compensation among rank-and-file employees (both individual contributors AND managers), with some managers earning more and some individual contributors making more. Probably no more than a 2X difference between what a junior engineer makes and what a senior engineering manager makes.
However, there's going to be a HUGE gulf between what they make and what the senior executives make--anywhere between 3X and 300X. That's where you go to escape the "salary squash".
Let's not confuse engineering with programming. Most programmers aren't engineers (don't have engineering degrees, aren't comfortable with physics / calculus, etc.) Real engineers generally don't have these employment issues as they age.
Programmers are 'engineers' in the same way that those with an MCSE are 'engineers' -- they operate a computer and employ a unique and useful skill-set.
No true Scotsman. What's an engineer? I'd argue that people who studied software engineering for four or five years, then became software engineers, count as engineers. The fact that they don't have much insight into physics is wildly irrelevant.
In Canada, a programmer is certainly not an engineer. And for Canadians going for a TN visa to work in the US, programmers are not allowed. Usually they try to slip in as 'Systems analysts' or craft the job/acceptance letter to fit under an engineering discipline.
Software Engineers are engineers in Canada. A self taught programmer doing css/html is not an engineer.
I'd simply qualify someone as an engineer, iff they successfully graduated from recognized university from an accredited Engineering program. And a second possible scenario is if someone's managed to pass all the Professional Engineer's examinations independently (rare).
Not sure if one should favour 4 years in theory or 4 years in relevant work, for a programming position. For research, yes absolutely as it is straight carryover.
That's an employers decision, my post was not meant to comment on how well someone can program, given their qualifications. Best programmer I know does not have an engineering degree.
Not sure why I got down voted. A quick google search will reveal my comment is factual. At least in Canada where I'm from.
"meet PEO's stipulated academic requirements for licensure (hold an undergraduate engineering degree from a Canadian Engineering Accreditation board (CEAB)-accredited program, or possess equivalent qualifications), and, if required, successfully complete any technical exams."
Here in Canada, I cannot advertise myself as a professional engineer without an engineering license. I'm not saying that this is the way things should be done, mind you, but being an engineer is a legal distinction in some places.
A big problem was that most bright engineers were promoted into management, so the ones left programming at 40 weren't so bright. So not so much that age killed the skills, it's just a selection bias.
I think we've got better at that and bright engineers are just being promoted into senior engineers, so hopefully it's fixing the selection bias.
"most bright engineers were promoted into management so the ones left programming at 40 weren't so bright."
Just wow. Quite a bit of agism there. In my experience most CEOs are not technical, and thy want "business guys" in management. This ranges from big companies (my manager at Amazon had a criminal justice degree and could barely operate a computer, and his IQ was less than 100) to startups (often the CTO will be technical, but also a founder, so there's not a lot of opportunity to become "middle management" during the startup phase.
Interestingly nearly all the guys over 40 I know who are "senior" devs never wanted to go into management. They just said "no!". They are solid reliable devs. They are all doing fine. But then again so are all the guys who went into management. (Sorry, I write "guys" all the time 'cause I grew up in the midwest - not trying to make it all about males)
Don't specialize in things that depreciate as rapidly as programming languages! C++ experience is quickly getting less relevant over time, but stochastic calculus, digital signal processing, machine learning, and distributed systems aren't. Some of those specialties get more valuable; in fact, sometimes, the forces that make things like C++ less valuable actually clear the way for things like distributed systems to become more valuable.
I was allowed to offer only a single bit of career advice, that'd be what I'd say: don't specialize in programming languages. They're a trap!
(But then, I'm not quite 40 yet, so I could be wrong).
When you're young, it can be beneficial to specialize in the "here today, gone tomorrow" technologies, because it negates the advantage of all the greybeards and lets you get exposed to levels of responsibility you wouldn't have a prayer of reaching for 10 years otherwise.
I got my first tech job (at 15!) because I'd taught myself Java, which was then brand-new, and a number of local companies needed experience with that and this weird new technology called the WWW. Parlayed that into a bunch of web experience, often as sole developer or team lead. Parlayed that into a job at Google, where I got to learn information retrieval, machine learning, distributed systems, the stuff that actually has a shelf life.
Someone could certainly end up at the same place (skill-wise) by getting a Ph.D and then a job at Google. The thing is, if you take that path, you're also forgoing work experience, income, perspective on how the industry operates, and the opportunity to jump off into different careers if you find you like them better. My first job out of college was writing software for hedge funds, for example; it turns out I hated the financial industry, but if I hadn't, it wouldn't have been too big a leap to get a job at a hedge fund after that.
The trick is to not kid yourself into thinking that the twelfth Javascript framework you learn is still valuable. The first gives you opportunities, the second and third give you perspective. But after that, have a plan B for things you should be learning that you can't get on the web. All that Java Swing stuff I did around 2000? Basically useless. Ditto the PHP in college, and even my Django & Javascript skills are nearing the end of their shelf life. It's the stuff I've done besides that, the stuff I generally don't talk about on Hacker News, that makes me valuable
The PhD route is different from the work route, it's not any better or worse. The PhD route allows you to pursue original research, hone written and oral communication skills, and in general allows for very different life experiences. Also, the work you can get with a PhD "can" be quite different than without (e.g. from a pool of ever shrinking research jobs).
C++ experience is quickly getting less relevant over time
I hear this often on HN and elsewhere, if I'd had to guess I'd also say it's true. But is there any proper evidence to support that? And in any case, it will probably still take decades before C++ will be gone. Maybe you could as well say: specialize in C++ now, in 20 years specialized companies will be begging on their knees for you to come work for them to keep their legacy C+++ stack working :]
don't specialize in programming languages.
Depending on the language you do need some level of specialization/mastering though else you might end up being writing very sub-optimal or even bad code in some languages. I'd say learning how to learn a programming language also pays off. Have you seen the amounts of SO questions for C from people who haven't reached a certain level yet? Their programs continuously crash or don't work as expected. Not necessarily because their intent is incorrect or they are bad programmers/engineers but more often because they lack proper understanding of C. Have you tried approaching Matlab the same way as any other language? Oops, there goes the performance. Working in Labview? It might look like it's easy (hey, all you gotta do is draw wires, right) but good luck building a medium sized application with it if you don't know at least some of the ins and outs. Now you might say 'if you encounter such problems you need to pick a better language' but that is just not how it works.
>Don't specialize in things that depreciate as rapidly as programming languages
C has been around since 1972 and is just as relevant as ever even as the popularity of C++ wanes. Python has been around since 1991 and is growing in popularity.
There is a trick to figuring out which technologies will stick around for the long haul, and it is one which most developers don't even think to try and hone.
My career advice would not be to not specialize in programming languages but to learn to distinguish programming trends from programming fashions and invest (with training/picking the right job, etc.) accordingly.
I doubt there is going to be much call for people with experience in Mongo in 5-7 years' time, for instance, but Postgres? Hell yeah. I predict increased demand for F#, too, but not so much for, say, Java (even though it won't go away).
I am a C programmer. C is my first language. I have shipped C code. I'm pretty sure I've literally shipped C code, in shrink-wrapped boxes. I took my kids to the museum today and hung out in the cafe pushing commits while they wandered around. What was I hacking on? A C compiler.
C is less relevant now than it was in 1996. A lot less relevant. Way, way, way less relevant. In 1996, most serious software was written in C. Today, only a tiny fraction of it is.
While true, in 1996 almost everybody knew C or C++. Now, you can get a CSc degree without learning a manual memory management language. While C and C++ are a shrinking segment of the entire market, the market is growing.
I don't get it when people say Java will be less popular. Today it is in most cases, my platform of choice. Modern Java is a damn fun development environment. You just need the right tools like Maven, IntelliJ Idea, Spring Loaded and so on.
I have written a lot of Java the last 2-3 years, with Maven, IntelliJ, and Dropwizard. This after years of C++, Prolog, and Haskell. Fun is not exactly the predicate I would attach to modern Java.
Of course, this is all subjective. But I can barely imagine that people coming from more expressive statically typed languages would like Java very much.
(That's not to say that the tooling for Java isn't extremely good.)
Yes, abstracting knowledge to the point of not being able to use or think in basic primitives is often counterproductive.
I can't think of a great example. It can apply to anything. Though your larger point stands, C++ is a not so great example. Many languages are roller coasters or extremely specialized. In contrast, C++ is on another upswing with C++11/14/17. It's used practically everywhere, especially in graphics, systems, and game development. A point worth mentioning is that good C and C++ developers are often capable of adapting to other languages and settings quickly. They're used to a lot of basic building blocks.
Worth noting that the style of C++ most common (in my experience) in game development is pretty far from what is considered "modern C++11 best practices", and the modern C++11 style tends to be frowned upon.
Thats not ubiquitous, but it indicates that despite the upswing, hitching yourself to that language is easier said than done.
Ok, lets see. The languages that I have seen come and go as intense fads:
* Easel
* Telon
* Powerbuilder
* Codfusion
* CICS (was actually taught in a "CS" course not too far from here)
* PL/I (may be not totally dead, sadly)
* IITRAN (maybe not that intense)
To Tom's point, I know of a project involving 300 Telon programmers who had to be let go when a massive project failed. Few who invested in the above technologies are working in them today.
More importantly than the article says, develop skill in solving business problems using your programming skills.
None of these are programming languages in the sense people normally use the term (with the exception of PL/1). They are propriety frameworks and tools. Even PL/1 was an IBM developed language.
Proprietary frameworks, products, and tools are definitely a terrible thing to base your career on. Languages such as C, C++, Java, Ruby, etc. are a good investment.
I was maintaining a custom piece of PL/I software until 2010 when I changed jobs, as far as I know the place is still using it. I suppose I have potential value as one of the few people (barely) under the age of 40 that have experience in it.
I would like what you say to be true. However, I have three of the base skills you mention, but I can't get the time of day from most companies unless I did it in their language or platform of choice.
I think it is just a reality of the current state the industry is in. Everyone seems to want developers who are already trained and experienced in what they are using so they can "hit the ground running", at least for non-junior positions. I think that is the biggest impediment for more experienced developers.
Agree and disagree. I think that learning the minutiae of a specific programming language might be an evolutionary dead end. I say "might be" because there are C++ engineers making $500k in HFT. Since we're both in the same city (Chicago) now, we both probably know some of them. C++ isn't dead yet, and it's not even close (but a mediocre C++ engineer is probably hosed).
What seems to happen as a technology fades out is that the number of jobs drops, while the pay in those jobs increases. There's a risk to it. If you continue to be qualified for those jobs in the depreciating technology, then you're solid. If you lose at the game of musical chairs, you can be screwed.
There's value in learning programming languages if you keep an eye out for the concepts that make them what they are, and if those concepts have a future, which is more likely. We may not need C++ in 25 years, but we are going to have low-level programming problems that require a C-like language (and fluency with assembly languages). Haskell itself may or may not be around in 25 years, but the problems it exists to solve and the value of static typing will still be relevant. Common Lisp is nearly dead, but Clojure is doing well. Languages die, but concepts hibernate at worst.
The people who will be screwed are the ones who specialized in minutiae of Java but forgot the computer science itself: the ones who got really good at JVM configuration and Spring and Hibernate but have completely forgotten how computers really work. The really good ones will always have jobs: there'll be Java work 50 years from now, just as there is Cobol work now and some of it pays very well, but the more average engineers who only learned The Java Way will be screwed: not good enough to get the dwindling (if well-paid) Java jobs and with too much atrophy of their general CS knowledge to handle whatever is next.
The C++ engineers making $500k in HFT are more due to the HFT part of their skills. As was said elsewhere, focus on solving business problems with engineering skills, not so much on the language.
Fair enough but my general sense of it is that extremely low-latency C++ is harder to learn than the finance part of the job. If that's wrong it's still what hiring managers believe.
I don't think it's ever wise to specialize in only a programming language, even if it's a really good one like Haskell. I think it's important to have a lot of language-agnostic knowledge in one's skill profile in addition to knowing at least one language very well.
Or plan C. For younger engineers start thinking about financial independence. Software Engineers enjoy a high starting salary and an even higher mid career salary so it is entirely possible to achieve financial independence in your 30s-40s with a frugal lifestyle and smart investing.
Ya it is hard to say. From his POV - he is already "retired", so he has tons of time available and if doing things himself limits his expenses - win win.
For someone who is busy working.. it depends. If you get a salary to work 40h a week... does hiring a poolboy for $20 an hour instead of cleaning your own pool for a self-declared time worth of $50 an hour make sense? I am not sure. If you are consulting and your choices are bill 45h and have a poolboy, or bill 40h and have your own poolboy... then the logic is much more in favor of outsourcing your tasks.
The other trick is how much do some things really cost? I know to pay someone to put brakes on my car, I would pay the equivalent of $100-$200 an hour. For $100-$200 an hour, I will gladly crawl under my car and get dirty!
Age has got nothing to do with programming. Ageism is just a bias (or fear) that some people have of losing their talent or skills.
Trust me, it doesn't happen.
What happens, instead, is that people get bored, or stop coding and lose the skills they don't practice, or get offered better paid jobs in management, etc.
Years back, maybe programming didn't have much to offer in terms of personal growth, I don't know. It's certainly not the case today -- I see people growing into better and better programmers, more rewarded, but also more interested, as time goes by.
Most companies you actually want to work for don't care about your age. If they do, is because they are just going to use you (like, code for 80 hours because you don't have a family and don't know any better...)
Now -- the real problem is that most people in programming really have no aptitude, skill or passion for it, and should at some point get out... but that's just me being an old fart ;-)
I think it depends a lot on the industry, a young SF based Rails / Django / based startup? I hardly see them hiring a 40 years old with kids that will ask for a salary higher than the CEO. A front end UI developer with knowledge of the latest Ember / Anguler / React / whatever they come up with next front-end tech? Perhaps they are more likely to find a fresh graduate (or just a self taught hacker who just rocks at HTML CSS and JavaScript) that is in their early 20's
But in big companies (Amazon, Google, Twitter) in enterprise software companies, banks, medical tech, finance, I think it's not that uncommon to find 40 year old developers. Most of the developers in my company average at way above 30. And we have a couple of engineers above 50. All of them are pretty kick ass Java developers and they all get tons of unsolicited recruiter spam.
(Maybe I'm delusional or in denial, or perhaps this is just the difference between industries, but I think that if you WANT to still do it while you are 40, and you keep yourself sharp, just like doctors have to keep up every year with the latest developments in medical research to stay relevant, then I think you can do it till you retire)
I think the reason many drop out of coding is that it is very time consuming to keep up, and some may want sometimes a less mentally demanding daily routine. Managing a team of engineers can be tough, but it's somewhat less mentally and intellectually strenuous and energy hungry as coding. Coding takes a lot of focus and sharpness, and sometimes it's simply hard grunt work, people sometimes get tired of it and want to move on to management (or being a "solution architect") or even product management.
I think the problem is that the 40 year olds chose on their own to do less coding at some point, and more management / IT / architecture. (e.g. the less good developers, those who don't pass the sort from 100 to 1 but still manage to land a job, eventually understand it's not for them and move on to other, not less important roles)
"I hardly see them hiring a 40 years old with kids that will ask for a salary higher than the CEO."
This preconceived notion that a manager or CEO must earn more than their employees doesn't make much sense. It's just a status game. If that developer (regardless of their age) has skills and experience that the company needs, and those skills are harder to find in the job market than management skills, it makes sense to pay them a higher salary.
Nobody questions the fact that baseball players and movie stars and investment bankers are paid several times more than the president of the U.S., so why shouldn't developers who are in high demand be able to make more than a CEO?
> But in big companies (Amazon, Google, Twitter) in enterprise software companies, banks, medical tech, finance, I think it's not that uncommon to find 40 year old developers.
I think there's a bit of survivor bias. More interesting are the stories of someone who's not at one of those large or old-school companies. There's a bunch of skills (MFC, Flash, microcontrollers) that used to define 95% of someone's job, and are no longer relevant.
Are there really people out there who actually believe that programmers are washed up by the time they hit 30?
I'm not kidding... do people really believe this? I always thought that was a fairy tale that employers tell to still-wet-behind-the-ears kids in order to pump up their egos so that they work untenable hours for meager pay
Yes, it has nothing to do with productivity but definitions. After 30 programmers see more options and its harder to keep them as cubicle/hipster drone.
42, happily but anxiously still coding. What most disturbs me about the ageism debate is that so many young programmers believe it is right, natural, and inevitable to assume that older programmers should be cast aside. It is an odd form of false consciousness that so many of us believe in our 20s that we will be retired before 30. Someone mentioned Barrett's quote astonished that "clueless management" would treat programmers' careers like those of professional atheletes. But how clueless is it really, when so many of us think the exact same way?
We all think we're going to be the lucky ones to strike it rich, all it takes is hard work and our natural talent and voila, $100M exit. Then, you reach mid-life, and still want to write code, how do you feel now about your youthful cavalier attitude?
If I could travel back in time 20 years and tell myself "dude, someday you'll be my age too!" I probably wouldn't have done anything differently, but it would be a serious boost to the humility of our young brethren for them to realize that they too will be in our shoes one day--a day that comes far too soon.
The thing is, I am actually one of the lucky ones. I could retire now and never work another day. Sure I don't have a private jet or a house in Atherton, but I have the freedom to walk away from anything and not worry about money. It's liberating, but I certainly don't want to stop. I love programming! I want to keep working. And based on the sentiments of those around me, and the nice paycheck I command, it's clear I still have a lot to contribute to this economy before I'm put out to pasture. But I would like a less toxic enviroment. Fortunately I don't encounter many clueless managers these days. I simply don't work for organizations where decisions would be made to hire youth just to save a few bucks. But I still encounter the young bucks who think I'm too expensive and simply there to steal their thunder and take credit for everything. Just remember kids, someday you will be just like me, if you're lucky.
We have so little time, don't waste any of it comparing yourself to others--young or old. Treat every day as a competition with yourself... to end the day a little bit smarter, a little wiser, a little bit more humble than you were when the day started.
I'm always surprised how timid programmers are; I have a very big mouth and I am very confident about my abilities. That alone seems to get me into anything I want even if I was bullshitting (which i'm not). So people who are far better than me at what they do as software engineer should have no problems at all. However most of who I meet and interview are timid and not very confident. Programmers in general really undersell themselves; even if they did great stuff, they will wind it down to things like 'I built some software which gets input from workout machines' vs 'I wrote an embedded OS and optimized (32kb it has to process the data!) analytics software which runs on most of the machines in YOUR favorite gym'. Or 'I did a C++ fast cgi e-commerce backend for an auction site' vs 'I wrote the backend for an auction site doing 400 million euros of transactions a year with millions of pageviews per month'. When you get above the 'junior programmer' people want to hear what you can 'get done' not some tech details of something which sounds like you just came from uni. I think a lot of people underestimate how much people will rely on them once they are seniors and if they don't have that air, why would anyone hire?
All programmers above 40 (and 50) who are not afraid to sell themselves are employed (and/or wealthy); the timid ones sometimes are but mostly are not; they complain that no-one wants to hire them. I don't think that's different in any other profession to be honest at that age.
I see no one else has mentioned another, even more obvious solution. Retire.
With the sky-high salaries it is possible to earn as a software engineer, it should be straightforward (not easy, but still straightforward nonetheless), to save enough to retire at the age of 40. After which, you can spend your remaining time as you see fit, working on personal projects or any other hobby that suits your fancy.
It's possible. I did it. I am 43 and I retired when I was 40. I lived frugally in Silicon Valley and saved and consistently invested more than half of my income.
It was a decision I made when I was 23. I remember doing a spreadsheet at that time to plan it all out. This was back before there were good references on how to plan it out. Some of my assumptions were a bit off, but I got there in the end.
Yes but you must realize it can't work for everyone. Clearly you made some smart decisions that involved a lot of sacrifice to end up in this position, and I'm not denigrating that at all. But a) not everyone has the ability to make those sacrifices (child care, elder care, health emergencies, etc) and b) even following the same path as you did could lead to a different outcome. There is an element of luck that, again I'm not discounting your achievement, does factor into the outcome.
We need programming to be a real career. People shouldn't feel pushed out when they are in what in any other industry would be considered the prime of their career. This mentality is destructive not only for us but the economy as a whole.
Can you give more details on your story? I'm particularly interested in how much you needed to retire, and how you've set everything up to make yourself comfortable that you won't run out of money.
This subject has been researched in great detail. There's lots of great information all over the Internet. I recommend these two blogs if you want to learn more:
The TL;DR is this: you need to be able to live off about 3.5% of your portfolio for one year. That will allow you to avoid depleting your principal over a very long term, and also give yourself an inflation-adjusted raise every year so you maintain your spending power. Often people quote a “4%” rule, but I think it’s meant for people that retire at a more “normal” time in their lives. The extra 0.5% actually makes a big difference in the probability that your portfolio can fail.
So, if you have a million dollars, you need to live off $35K a year.
If you’re willing to really change your lifestyle, you can retire off $500K, which would give you $17K a year. It doesn’t sound like much in Silicon Valley, but that will put you in the top tier of income in a place like the Philippines.
I don’t want to post my own net worth because it might come across as chest-beating. I’ve been living in a few places that are a lot cheaper than the United States, so my expenses are low. Over the last three years I’ve been averaging living off slightly less than 2% of my net worth annually. So, I’m REALLY safe by the “3.5% rule”. My net worth is higher than when I retired.
I’m enjoying my life. Every day is a clean slate. There is nowhere that I have to be at two o’clock on a Tuesday afternoon. I can read or take a walk, go to the gym, or tinker with some computer language. I like this life. I sure hope I did all the math right, because if I have to back to a cubicle in Silicon Valley it’s going to be REALLY painful for me. No amount of free sushi by your employer is enough to compensate you for your lack of freedom.
Essentially, your income in retirement should not be dictated by your current income, but by your current level of expenses. If you can save a multiple of your current annual expenses, and that multiple is high enough to account for real-terms investment gains, you're financially independent: you don't need to work any more.
The number generally used is 25x, which corresponds to real-terms gains of 4% per year on your savings.
The S&P 500 is 50% above its 2008 peak on May 8, 2008.[1] That's a 5% annual compounded return ((210/140)^(1/7)). And that's using the 2008 peak: if I use the lowest price from 2008 (in December), your return would have been 8.8% annually. Inflation (at least in USD) has been benign during this period, so probably there has been a real 4% return during that period. I don't know how you concluded that you didn't get a 4% real return during this period.
If you look at the stock market over any short-term (<15 years) it will be quite volatile. Over very long periods it is more regular. If you're investing in the stock market, you must take a very long time horizon.
If you really want to understand this topic in more details and whether your portfolio is likely to fail over some period of time, I encourage you to play with FireCalc [2].
Or buy now and sell in 15 years or so. Move to Boise Idaho. 15 years of equity (ignoring appreciation) means you can buy a house twice the size outright.
Bay Area real estate has picked up, but timing 15 years to sell? Doesn't always work out as well as it could if things have cratered. There have been about three significant real estate collapses in the Bay Area in the last 20-30 years.
Some areas hold up better than others, but, say mountain view, a 20-something at his/her first/second job, unless has other means, isn't going to pick up property easily to hold for 15 years.
Affordable areas in a boom? Those most likely to take a serious crap in a downturn.
15 years isn't exact. Boom bust cycle is 5 years or so. If the market is down in 15 years, then just wait it out. I'm not even including appreciation in the calculations.
True, and not everyone will want to dig up and move to Idaho. Established roots, friends, etc. There is more to "home" than just the walls in which you sleep.
This article is wrong on the facts, but more dangerously offers wrong advice on life choices.
23 years ago, when I was 23 years old, I actually posted a Usenet question on this topic (archived somewhere?) asking where were all of the "old" programmers?
First off, people don't decpreciate, skill sets do. Of course someone making a high salary will be undesirable if their skills stay the same and become commoditized or less relevant. But the same would be true of a young person with the same salary/skills. Every time this happens the challenge becomes finding the next niche that is valuable, and that you like enough to devote lots of time to.
Secondly, a lot of older folks get siphoned off to management voluntarily. This can happen when a company doesn't have equal career ladders for tech and management. At good software companies you can advance as individual contributor up to a VP level, while other companies force a switch to management to continue progressing. And of course a few are natural leaders of people who want run a group, or try a cross functional gig. Some feel it's more prestigious to be director of whatever dept.
On age discrimination in tech, I hear about it anecdotaly, but haven't yet perceived it happening to me. Maybe it's just too early to notice, or maybe there will always be some people in tech who want to work with the best team possible regardless of age? Would I hire an 80 year old developer? They'd get the same questions as any 25 year old. Show me the code you've written over the last year. Shoe me how you communicate complex concepts in simple ways. Are you a dick to work with?
On being too expensive, the reality is there is an effective salary cap for everyone which is a function of company, role, skills, location, etc. You need to know what the cap is and realize if a company balks at going over it then it may have nothing to do with age. The calculus is what it is, older people are just more likely to hit the caps first.
Finally I must disagree with the comments I see about young people being less capable. Yes, experience is irreplaceable in certain contexts. However more often I notice the people doing really great work are a special minority of individuals that just have the right combination of smarts, drive, maturity, flexibility, luck, etc.
I'll try to remember to follow up on this post in another 23 years to discuss what has changed.
i'd suggest that intelligent employers realize that the language and stack are only a very small part of building a product. The more interesting problems are hard not due to language, but due to algorithms, data structuring, design patters and general architecting et al.
The 10yr C++ programmer ought to have those things nailed, the junior may not know they even exist.
Right. The issue here is that there's a difference between a software engineer and a programmer. A programmer is measured by years of experiences with particular technologies. Programmers are unfortunately replaceable commodities as a result. Software engineers are measured by their ability to work within constraints to use ANY tools available to them to solve the problem on time and in such a way that it'll scale to load.
If you're in a workplace full of programmers, consider moving onto to a firm that hires software engineers. You may have to move out of state unfortunately since the culture doesn't exist everywhere.
> problems are hard not due to language, but due to algorithms, data structuring, design patters and general architecting et al.
This is where I think we do get some legitimacy to this discrimination though. Most places you go, people are implementing functionality that is not terribly unlike that which has been done for the last 20 years (I'm talking the generic business "enterprise" shop). However, there seems to be about a ~~20% turnover in tools, styles, patterns, etc every year, and in my opinion at least on some platforms, the implementation style is tending towards the most complicated possible over-architected solutions possible.
When you're young and single, you have all the time in the world to keep up to date on all this, but once you're married, not so much. So, while I could easily out-implement the more "current" people, I'm not up tp speed on everything in their toolbox, so I lose.
As you say, "intelligent employers" should realize this, but how are they to know the technology flavor or style du jour is a waste of time, when the industry itself can't figure it out? ("everything XML" as just one example)
that's a good suggestion. it will fall on deaf ears because employers don't read anything on the Internet and they hate engineers, especially old ones. they can't get basic things like don't sexually harass employees right, so how are they going to get age discrimination right.
I don't buy it. There are people of all ages on my team, and the same has been true at several other jobs I've had in the past few years. There is not even a particularly strong correlation between age and seniority.
My second observation is that in all the jobs I've had where this was not true, the company has not been particularly successful in the long run. It's unclear whether this is related, but it's interesting.
However, I can come up with an alternative statement that may be a better explanation of what some people seem to observe: if you are not a really good engineer by the time you turn 40, and you expect to be paid based on your "years of experience", get a plan B.
Ehhhh. I'm 40+ and I've never had so many opportunities. Then again, I love this stuff, so it's not really work to keep up. I still love the shiny new thing, and my ramp-up is faster since I've seen most of it before. It's just another language, platform, what-have-you. I worry more about the income plateau. I wouldn't leave because I'm tired, slow, or specialized. I'd leave because the market wouldn't bear my rate growth.
In most software jobs, it's impossible to directly quantify value-added. So the engineer's salary is 100% determined by your employer's (or by proxy, manager's) opinion of how much value you add.
And those opinions are quite locally specific. In my current place, we value age and experience perhaps more than many other shops in SV. So you're right, I think it doesn't "generalize", it depends on one's work culture.
I always find these discussions kind of odd, because there seems to be an unspoken assumption that the world is divided into 20yo CS grads and 40+ greybeards. The truth is that a lot of people get into software outside that track nowadays. Their initial ambition either becomes obviously unrealistic or increasingly unattractive[0]. Hence the phenomenon of boot camps, etc.
I'm sure there are people who do twelve weeks of ultra intensive rails and think they're Dijkstra incarnate, of course, but most of us who came to development, as it were, sideways do not exhibit that kind of attitude. We respect our elders.
I have no idea what it's like in the valley start up scene, but certainly in London I see very little buggering about of senior engineers: nevermind people considering me basically past it at the row old age of, er, 28.
After reading stuff like this I never know what to think. I am 28 and just getting started. I hope to land my first developer position by the end of the year. So what am I to make of it? By the time I am competent enough I will be expendable? I am not discouraged but articles like these don't make sense to me. Almost everywhere I look and in every aspect of my life I am always "behind" and I don't feel like it but everybody is telling me I am...
A programmer will never ever ever ever be expendable, in fact, demand for programmers just grows everyday and we just started wiring the Internet on things. I am 40, I just had my first kid, I do not have a ton of karma in HN ;) You are never behind, just follow your own path...
Congrats on learning to become a developer. Always excited when people join the community. A few things:
1) that feeling of "being behind" never goes away. In fact, the more you learn, the wider the breadth of topics you will want to learn, so the feeling only grows. Software engineering is not a field which lends itself well to people who want to "learn the playbook so they can be confident they are doing it right". The main question is if you can spin "feeling behind" into a positive force, similar to what competitive athletes do.
2) if people are telling you that "you are behind" - ignore them and start hanging out with better people. There are more than enough talented people out there who want todo nothing more than help others while building up their confidence in the process.
I only became a semi-fulltime developer after 40, but I have the advantage of working for myself and 20 years of non- software domain experience. I think the key to developer longevity is having other skills so that once your percieved value as a developer declines you have other skills to fall back on.
I really didn't see any issues other than day-rate-compression through my 40s. Now I'm nearing 50 my memory definitely isn't what it used to be, but my expression in code is improving to compensate.
I feel that my influence and ability to drive good outcomes gets better as I learn more about myself, but the nurses here are telling me to go back to bed, so I'll have to turn off this computer thing now.
I personally hate working in a monoculture, whether it's all males or all 20-somethings. There's just inherent value in having diversity in all dimensions, otherwise the workplace turns into a military barrack.
Turn 38 on Monday. I turn down work regularly (and I've been guilty at times of not turning down enough work). At the same time, I look much younger than I am (I get carded regularly), wear mostly conference t-shirts and hoodies, wear "hipsterish" glasses, and have a stickered-up MBP, so maybe I fit a stereotype not becoming of my age.
Here's a plan: move outside the Silicon Valley circle jerk. You won't get a ridiculous superstar salary, but you get the chance of working on actual products instead of throwaway MVPs.
This is a worthwhile consideration for all of us. I do think it's helpful for your career development, socialization, skill and salary advancement, to spend some time in the "Capitol" of SV. But leaving before it burns you out is also something to keep in mind.
I actually moved here not if my own accord, but following my spouse (who isn't in a tech field). Luckily her career is very stable, but even with 2 fat incomes, the cost-benefit ratio of SV life is a difficult proposition.
There are lots of good jobs to be had in smaller markets, and with less douchery comes a bit more humanity and respect for people and their skills.
According to a survey conducted by the National Science Foundation and the Census Bureau, six years after finishing college, 57 percent of computer science graduates are working as programmers; at 15 years the figure drops to 34 percent, and at 20 years -- when most are still only in their early 40's -- it is down to 19 percent.
What they fail to talk about is the 7 different occupations similar to 'computer programmer'. Are you a Computer scientists and systems analyst? Or a Network and computer systems administrator? Is your job title Computer software engineer? Maybe you're a Electrical/electronic engineer or a Computer hardware engineer? Then you are not a Computer Programmer.
NYT cherry picked one occupation of many. If you're 40 and you've migrated job titles past Programmer, you contribute to this 'rampant ageism'.
I sometimes think, that the reason for this age discrimination was the switch from female to male coders in the early 80s. It was that sudden break, that introduced the computer kid as a replacement of the former cheap female workforce, and made the highly payed former system architect obsolete, as nobody had a use for a programmer anymore, who needs a secretary for typing, in the modern time of personal computers. Some of them moved to management, just renaming their job position.
So the gender discrimination of cheap female coder vs expensive male system architect switched into an age discrimination between cheap young coders, and expensive managers.
We lost both the skilled and the female coders in this way.
I'm giving an offer to someone about as old as my father (over 52 easily) because he shows interest in the subject I need code written in, has proven shipped projects with success over decades, and is reasonably competent at the details. My employer is not a Bay Area company though and we are not trying to crank out code on a relentless mission like most are - we're looking for something a bit slower paced, thoughtful, and more "right amount of effort" for fairly simple tasks that I've found require some real world experience to get right. As a result, we're actually biased against younger employees if anything, not the other way around.
This uncertainty is one of the things that drives me towards getting a CS PhD and ultimately a research position rather than becoming a software engineer. Older researchers are very common in CS-related fields, both in industry and academia.
Working in the Austin startup scene, I definitely get a sense that this is an issue amongst younger companies. However, I look at my father who's now with a massive merchant software company and there's not a single person in his division under the age of 40 (a lot of these guys are maintaining legacy mainframes, etc.)
About a year ago, the company realized that they're SOL with a n aging employee base and no one coming in to replace them once they retire. He's always argued that larger companies will come calling once the boomers are out, but I shutter at the thought of having to learn COBOL.
I had to learn a tiny tiny bit of COBOL to help transition some mainframe code from COBOL -> Java. If you are just reading it to gut the program, not a huge deal. You can play with the inputs and outputs and verify your work.
Now having to learn COBOL to maintain it? That seems not fun. A simple change can take days...
My plan B is to semi-retire. I expect that I'll still work some, but starting somewhere around 40-50 I plan to cut back to part-time (or perhaps stints of full-time intermingled with multi-month vacations) and become more picky about what I choose to work on.
Assuming I never get another raise in my life, I'm on track to have my house paid off before I hit 35, and $500k+ in the bank by age 40. (The better portion of that will be locked in a 401k until I'm 60, but my wife and I have also been maxing out Roth IRAs and that money will be available to retire on whenever we want it.)
I'm not a fan of this plan B stuff when you're 40.
Where is the plan B for doctors? Where is the plan B for Lawyers? Why do these other professionals have respect in the their old age and not us software engineers/programmers?
How depressing.
> The half-life of an engineer, software or hardware, is only a few years.
And I still don't get this. Move out of software and you'll find loads of over 40's and over 50's engineers. Here in Perth I know loads of older engineers, that are given dignity and respect along with their peers in Medicine and Law.
This plan B stuff is because of the culture that surrounds programmers. If there is any plan B, it is to maybe start admitting that older programmers might actually be useful and worthwhile for employment, much like every other white collar profession.
It's true that a 40 year old might not be able to work as many hours as a 20 year old, but that doesn't mean each hour is worth the same. At 40, you'd hope that the older programmers hours put in are more considered with all their experience and are most certainly worth it.
The same goes for older Lawyers and older doctors, they might not be as energetic as 20 year olds, but with all that experience to make that much more of an informed decision, it certainly means the older generation can compete.
This is a culture issue.
> Software engineering reliably undergoes a major technology shift at least every 10 years.
I doubt any shift invalidates real fundamental knowledge.
Sure if your entire career has only been a couple of languages with very little algorithm theory, then true, but that's because you never studied the subject, on your own or formally, that isn't because you're 40.
For example, Doctors and Lawyers have to have the fundamentals down, it's very important. I guess it's true that not enough programmers have the fundamentals down and that is an issue.
But if you're 40 and have training in the fundamentals such as algorithms and design before even hitting the code, you should easily be able to adapt.
> The more irrelevant experience a candidate has, the more lopsided the utility/value equation becomes
Again this is a HR issue. A software engineer/programmer that starts their work from the design and algorithm level should be able to pick up a new language in a couple of weeks. This issue is mainly with the way we hire programmers not with the programmers themselves.
It's like the job ad for 10 years experience in Node.js when Node.js was 3 years old. Just because HR are clueless doesn't mean we need to all start changing our careers.
If you want my advice, it's learn that knowing people is as important (or more!) than what you know.
If you build up your career around being an expert and networking, you will be in a better position than the expert who knows no one.
>Where is the plan B for doctors? Where is the plan B for Lawyers? Why do these other professionals have respect in the their old age and not us software engineers/programmers?
They have unions.
Doctors and lawyers also have strong protections from foreign competition. It simply doesn't matter if you are the best doctor or lawyer if you trained outside of the United States. You won't be allowed to practise until you qualify in the US.
I completely agree and the sad truth is that we software people do it to ourselves by devaluing the contributions of older/more experienced people.
OTOH if we move toward a more professional / credentialed / high-status profession that won't be all roses, what with exams, high barriers to entry, slow/uniform career progression, etc. I don't like not having a plan after 40 but I do enjoy how meritocratic the industry is, and how it really does reward hard work more than just, say, years worked.
If it doesn't work and you don't earn enough, build your shit.
During your career you'll be able to build 3-5 relatively big projects. And about 10-30 small projects and ideas.
And if you're lucky enough, you won't worry about that anymore.
I earned x3 salary 5 years ago. I had freedom, and I could work 5-10 hours a week. But finally my project has failed. Lesson learned. Now I'm far behind these figures.
But I keep on trying building shit. Hopefully, I'll be able to turn it to successful business one day.
Please describe the "shit" you would like us to build. I'm asking seriously.
Are you saying we should build a big open source project like Angular or Rails? What are the odds that either of us could build the next Rails though? So are you saying that even if it "fails" and it doesn't displace rails that this is good for your career?
Basically could you explain what you're trying got convey in really concrete terms?
I'm not disagreeing with you, I think you might be onto something or have a useful perspective, I'm just not sure what you're really saying.
I'm talking about your own SaaS projects. It's relatively easy to build something on your own, if you're developer. Some kind of tool for business. When you can charge monthly for your product.
Even a very busy person like me can find ~1-2 hours daily for development, and you can think about how to implement what you want in car, bart, on the way home, etc.
I just had dinner with two other devs tonight I randomly met at PyCon. Both of them do contract work, and have to turn away work. Neither of them ever specialized in any particular language; they both just focused on using code to solve problems.
There's always going to be a need for people who can walk in to a new situation, diagnose what's going well and what needs to be fixed, and carry that out.
One needs to implement life long learning! We are working in a field where there is exponential growth in computing, networking and storage and what computers can do. The robot automation artificial intelligence age are coming!
Ordering food will be automated, cooking food will be automated, the post office will be automated. Shopping will to a large extent be automated, there will be 3D models of your body captured by your cell phone or 3D scanner booth. When you enter the shopping mart of the future, the food will come to you, you will not pick it up unless you want to. Why use a shopping cart when you can have a robotic picker do the work for you?
That said I see different things in different people getting older. Some people like life long learning, they will not have an issue finding jobs. Some people stagnate in their internal development after college, they use the same programming languages and tools as they did several years back. They are probably more in danger of getting obsolete by new tech. I think there is danger in your career path if you stagnate as a growth as a person. This will get worse the older you get unless you change.
With years of experience you will also realize that there is fashion in programmer tool chains, it's not necessarily that Javascript is better than say Ruby or Python but it sure is in fashion. Same can be said about NoSQL tech such as MongoDB it is not per say better than sharded MySQL and Postgres but you should still learn it because your younger peers will like it. I like to learn new stuff so I follow along. This also covers fashion in Javascript libraries such as AngularJS and React, there will something greener in the library field down the line I'm sure of it.
Love to learn! If programming is anything like martial arts you will just get better and more skilled with age, take and go the new tech coming in.
I don't want to go into managment or consulting, I love being a developer. There is just this misconception that companies think it is a reward for you to put you there. "Hey this guy is really good at developing software, you know what we should do, stop him from writing code and sit him in meetings with stupid people until he becomes one himself"
"While a technology shift doesn’t completely negate the skills of veterans, it certainly levels the playing field for recent grads."
In my opinion, a technology shift (new language, platforms, methodology, paradigm or whatever), doesn't come close to negate the skills you have aquired. In general, I think people underestimate how much of programming that is still the same. I wrote more about it in "Programmer Knowledge" http://henrikwarne.com/2014/12/15/programmer-knowledge/
60 something... they made the first PCs!
50 something... First PC OSs and compilers.
40 something... created the first web browsers, and founded the biggest, longest lasting Internet companies. Had to deal with C, slow computers, crazy memory mapping, OSes that crash.
30 something... started Facebook, wrote mobile apps, created hundreds of more narrowly focused internet companies using pre-existing tools.
20 something... hack PHP, ruby, js to create sites that deliver stuff to you. Utilize heaps of VC cash. The book is still open what they'll accomplish.
Before we talk Plan B, let's talk Plan A. The article equates age (and obsolescence) to Plan A. This is incorrect. Age is not a plan.
Plan A is continually improving your skills. Breadth and depth. Know one thing fairly well? Become excellent at it. Is there something way outside your wheelhouse? Get closer to it.
You can't do everything, but chances are there is something you can do to improve your overall skill set. The great thing about Plan A is that age has nothing to do with it. It's a personal choice that you control.
Not sure I add much worth to the view portrayed by this article.
However, as you progress in your career become a specialist in a particular field. Avoid becoming a general programmer. So far I've had two programming careers, the first was a games programmer, a very specialised area. The current is building high performance trading system in the financial sector. These are both very liquid and specialised area.
This will increase the likelihood of you being in demand, and afford you the luxury of options.
We work in a, relatively speaking, very young industry. It's very hard to draw conclusions by looking back at 20 years ago. Being in a young and highly-demanded industry pushes a lot of us into managerial positions earlier than normal. But essentially, I believe that a developer's age doesn't matter if he/she doesn't stop learning.
I get the impression that this varies considerably with the local tech culture. Apologies for making this about me, but has anyone encountered this problem in the Seattle tech market? I'm 36 now, and I'm thinking of moving there sometime soon. As a coder/sysadmin/general tech guy, is this something I should actually be worried about?
Is contracting not a viable alternative? At 40 I'd assume enough experience to be able to lend yourself to any struggling project that needs a talent injection?
If only there was a physical challenge during the hiring process, then this geezer would be a shoe-in! Arm wrestling, 3 mile run, pull-up challenge anyone?
I think a current bridge slowly being crossed is a move away from OO programming (along with GoF design patterns) towards functional languages.
GoF patterns provide structure (at the cost of complexity). FP patterns are simpler and succinct but aren't quite as cookie cutter and thus are less structured.
Probably the tick-tock of the pendulum swinging. As software became too unique to maintain, standard patterns were implemented. As standard patterns became overly complex, we swing back to more expressive constructs.
Yes, web to mobile. Native mobile development is a hugely different beast from web programming, just as web development was a huge shift from desktop GUIs in 2000, desktop GUIs were a huge shift from DOS and other microcomputers in 1990, microcomputers were a huge shift from UNIX and VMS and other timesharing OSes in 1980, and timesharing OSes were a huge shift from batch-processing on IBM & other mainframes in 1970.
It's interesting that you say the transition has happened between web and mobile, because of a lot of people I know are getting up to speed in HTML 5, and are betting the next few phase of their careers on it. Maybe it's because South Africa is a few years behind the curve, but is there evidence that the share of web-based jobs is declining enough to be concerning, in the first world?
The interesting thing about waves of technology disruption is there is usually more than one wave in play at a time, and so a technology can both be disrupting and disrupted. The web was invented in 1989, popularized in 1995, and arguably the point where people realized "Hey, desktop apps are in trouble" was around 2004 when GMail and Google Maps came out. Even so, Dropbox was founded in 2007 as a desktop software company, and that hasn't stopped them from being worth a few billion.
Mobile apps were invented in the 1990s (Newton, Palm), popularized in 2008, and (at least in Silicon Valley) it's a big topic of debate whether the web is dead. In my old job - Google Search - I was still pretty secure as a web guru. In my new job - startup founder - I feel that I at least have to do my due diligence and evaluate the technology.
Whether it's a problem for your career depends on exactly what you want to be doing with your career. There are still people making a living off of COBOL and IBM mainframes. In general, consumer markets peak about 5 years after the technology is introduced to the general public (so microcomputer apps came into their own around 1980 with Visicalc, windowing apps around 1990 with MSWord and various office suites, webapps around 2000 with Google etc, mobile just starting to peak now with Uber/Instacart/etc.) If you're founding a startup you need to account for the time it takes to build your product, so in general you want to use technologies not more than 2 years old. If you're working at a company you don't want to use technologies until the companies that have adopted them have gotten big, so it's frequently 10 years or so after adoption.
For some reason that I don’t completely get, a little gray hair and a smattering of experience in different technologies can create a beneficial bias for companies when they are renting brains instead of buying them outright. It may have something to do with the tendency for consultants to be vetted from higher up in the management chain where the silver foxes live.
I can explain this. It's a very old idea. The truth about the young hires is that they're cheap and the work they do isn't very important, but they're hired based on the potential to rise a level or few.
From an executive perspective, you don't hire juniors for the work they'll do, because it's usually not of high impact of value. You hire based on the probability that they'll be high-impact employees later. It's impossible to predict this at the individual level, so you're building a portfolio.
Of course, in 2015, the one-company-for-life model is pretty much dead and most people who get executive positions get them by job hopping at the first sign of an obstacle. Likewise, companies invest very little in their junior employees and tend to hire top-level talent from outside. So the biases from the old days don't really make sense.
If someone's 40 and still a junior or mid-level engineer, the assumption is that he's "too old" to become a high-impact employee in 5 years. It's completely ridiculous, these days. He could have been doing something else, like trying to make it as a novelist or working in a dive shop. It's a hold-over from the employment-for-life, gold-watch era.
For the consultant, he's not selling himself on some hazy "future potential" factor, so no one cares how old he is or (more relevantly) how old he'll be in 10 years.
Very few people actually think that young, junior programmers are more skilled or better at their jobs than the 50+ badasses. The issue is that the young juniors come with a 5% chance of being a high-impact, executive-level employee in 10 years. Since the people making big decisions are executives who tend to discount the importance of everyone but executives, this still matters... even though the one-company-for-life model is pretty much dead.
>This article is using information collated in 1998.
>I have met a lot of unemployed former Programmers though?
>When I was younger I has no idea just how fast 40 would come. One downturn cycle in the economy, and poof--you're there? (I do believe our bubble is about to burst again?)
>It does seem like certain young individuals come up with the most original ideas.(Certain, not all, and if you need to tell people about your brilliant ideas; your ideas might be very unoriginal?)
>When I was in my twenties, you couldn't pay me enough to sit in front of a screen all day. I would crack one those 500 page phone books, and want to puke. As I got older, my priorities changed, along with my ability to study boring things. Yes, I said it. I find a lot of computing boring, and very tedious. Ironic?
At 38, I'll admit that the general atmosphere of ageism in tech--whether real or not--scares me a bit. I guess I can take solace in the fact that, as a Data Scientist, I'm in a field that's too new to have rampant and widespread ageism.
In 25 years there has never been a moment when I wasn't in love with learning the latest cutting edge tech.
Over the years it's been so much fun...
...to progress from the BBC B to pascal on the mac to pc's to unix boxes to c cgi scripts to perl to php to mySQL to flash actionscript to ruby to javascript to noSQL to node to socket.io to html5 css3 to iOS to android to rabbitmq to laravel.
...to move from crappy first gen-linux boxes serving web pages from my front room to using web hosting companies to the elastic cloud to puppet to salt-stack to containers.
And I'm only just getting started.
I can't wait to get in to VR, 3D printing, hard core signal processing and so much more.
When I'm screen sharing and problem solving with a 25 year old dev on a hardcore problem I feel no different in any way to the person on the other end of the line.