Programmers: Before you turn 40, get a plan B (2009)
improvingsoftware.com
improvingsoftware.com
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.
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.
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!
The key is, no matter the age, to keep expanding your knowledge base.
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 ...
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.
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 ...
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.
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 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.
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.
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.
And I'm saying that as a twenty-something.
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.
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!
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.
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 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. :)
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/
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 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)
* The Brain That Changes Itself: Stories of Personal Triumph from the Frontiers of Brain Science - Norman Doidge ( http://www.amazon.com/The-Brain-That-Changes-Itself/dp/01431... ), great book
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.
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.
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.
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 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.
i.e. you don't bother to spend an hour to plan a project. I don't think anyone wants to work at those kinds of places, young or old.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.)
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!
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!
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?
[1] http://docs.scala-lang.org/overviews/core/futures.html
[2] http://akka.io/
[3] https://www.playframework.com/documentation/2.3.x/Iteratees
[4] http://www.reactive-streams.org/
[5] http://www.manning.com/bjarnason/
[6] https://www.edx.org/course/introduction-functional-programmi...
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.
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.
NPM either disproves your thesis or has an exceptionally high amount of masters in its community for a language at that level of abstraction.
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.
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.
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.
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.
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.
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.
At 25...
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.
How did it work out for you? I am curious as I am thinking of shifting from fin. applied math (econometrics) to SE ...
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.
Focus on eliminating the very need for the problem to exist. Than on workarounds.
someday i might get there.
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.
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....
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.
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 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.
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.
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.
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.
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."
Why generalize from one encounter with one 40+ year old developer?
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.
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 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.
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.
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)
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.
Personally, I'd prefer your answer.
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.
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.
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.
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".
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.
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 also think that salary data, with no corresponding ability data, will be meaningless.
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'.
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.
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.
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 why I got down voted. A quick google search will reveal my comment is factual. At least in Canada where I'm from.
https://archive.org/stream/TNVisaForSystemsAnalystsVsProgram...
"Many people do not realise that computer programmers do not qualify under the TN Visa"
http://peo.on.ca/index.php/ci_id/2057/la_id/1.htm
"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."
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.
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.
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.)
What about tinting ("dieing?" sorry for not knowing the word in English) your hair? It's superficial, but if it lands a job, it's fair.
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.
Look is important,unfortunately, but it isn't always about age, sometimes you're too fat, or not white enough ...
Or black enough... Or female enough... Or Non-foreign enough (yes I got this one before)... All sorts of stuff, to be honest.
http://www.reuters.com/article/2012/11/27/us-valley-ageism-i...
http://www.dailymail.co.uk/news/article-2239277/CEO-Randy-Ad...
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).
* 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)
More importantly than the article says, develop skill in solving business problems using your programming skills.
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 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
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).
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.
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.)
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.
Thats not ubiquitous, but it indicates that despite the upswing, hitching yourself to that language is easier said than done.
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.
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.
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.
He advocates doing things yourself, DIY etc.
If you can pay someone less to do something than you could earn in the same amount of time. Its better to outsource those tasks.
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!
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 ;-)
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 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.
MFC and flash can die though.
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 baseball players are paid more than managers.
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
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.
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.
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.
This is the route I am taking.
If you plan on living the life of a hermit workaholic, certainly reasonable with your life circumstances.
If you have a family, want to travel, or want to buy instead of rent, assuming the Bay Area, very idealistic.
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.
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.
http://earlyretirementextreme.com/
http://www.mrmoneymustache.com/
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.
That has been very difficult (at least for me) since 2008.
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].
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.
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.
The 10yr C++ programmer ought to have those things nailed, the junior may not know they even exist.
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.
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)
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.
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'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.
[0] this was me in 2010: https://m.youtube.com/watch?v=obTNwPJvOI8
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 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 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'.
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.
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.
Now having to learn COBOL to maintain it? That seems not fun. A simple change can take days...
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.)
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.
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.
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.
No matter how much time it takes, 1 year, 2, 3.
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.
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.
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.
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.
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.
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/
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.
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.
It's hard to predict the lifetime of the field you are planning to become an expert in.
By 40, there should be some success or direction into side projects that might become the main thing.
Quality product designers, architects and engineers that can deliver great products will be in demand until the end of time.
From web to mobile? What was the tough bridge to cross in the last 10 years?
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.
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.
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.