Then let me ask: how do you make it past 40 in software? Specifically, how do you position yourself so that you are actively sought after (rather than merely employable)?
I’m 40 years old and I have recruiters coming after me non-stop.
1) Don’t include irrelevant experience on your resume. Nobody cares that you were writing php websites in 1997. Try not to put anything on linked in or you’re resume that would indicate your age unless you’re one of the top people in your field and your experience makes you stand out.
2) Keep up with new languages. Don’t be the guy that only knows perl when everyone else is using python. If you aren’t learning rust and go today, you’re going to be left behind five years from now. And once everyone is on go and rust, you should be learning the next thing.
3) Stay curious. I know you have a family and kids and other commitments, but you have to stay interested in the world. Keep up with business news, and science news and stay connected with pop culture as much as possible. If you’re applying for a startup with a bunch of 20 or 30 something’s you, you need to be able to meet them where they are.
4) Don’t get complacent. You’re always a bad quarter away from getting laid off, and that becomes more true the older and more higher paid you are. Keep your resume updated. If recruiters aren’t beating down your door, you need to ask yourself why. Because if people aren’t trying to hire you, your employer probably isn’t excited to keep paying you either. I was a junior guy on a team with all sysadmins 5 years ago. They were all the same age as me, but with many more years experience all at the same company, doing the same thing and really resistant to changing. I came in and really dove into the deep end with devops, despite having little programming or sysadmin experience (I had a networking background). Within 5 years I was a senior developer, making more money than any of the rest of the people on the team, and eventually got poached by a recruiter offering 40% more money. They’re all still there barely holding on to their jobs.
I'm 50 and I've been a freelancer since 2006. I position myself either as developer (Rails and jQuery back then, still Ruby and Python and Elixir now, I'm starting to code with React) or architect and coordinator of developers. That works well with small companies. I attend to tech events in my city (Milan, Italy) and I organize an event myself. It's a good way to keep the word of mounth going on. I don't know if this is a feasible strategy for the next 10 years, but who knows what's going to happen by then anyway. I'll adapt.
I spend a lot of spare time doing work for previous customers while being on a full-time project at the same time. Keeping multiple customers warm is a must. All paid though. A few weeks of not having a full-time engagement means finally being able to clear out the backlog and enjoying long weekends.
Every year I take an unpaid break for over a month around the holiday season. I love it but it always is a bit scary to be away from customers at the same time.
Reasonably well. I made more money with my last job as employee, which was paid above the average of the market. However I own my timetable now and I work mostly from home. That is worth some money too and it improves the quality of life, which is hard to quantify but it's very important. I'll never be an employee again unless I absolutely have no alternatives.
My father-in-law is pushing 70 and still coding. He just semi-retired, but up until last year he was employed, despite having little in the way of social skills and living in a remote area, far from any coding hub. If he was just a bit more personable and willing to move within a couple hours drive of Boston he could have fielded multiple offers.
Pure anecdote, but if you're decent, have a little hustle, and don't mind working in a soulless office park, it seems like you'll never struggle to find a gig.
Java and Spring, or C# and .net. Java is derided as the next cobol, but there is a lot of new development, lots of jobs, and strong demand for senior talent. Source; me, been doing java since 2003. Age 40+.
Can confirm. Also, I suspect a lot of this "there's no life after 40" stuff mainly relates to startups and certain small companies. It certainly doesn't apply to BigCorps.
I suspect this is true. I hear the "middle-aged programmers aren't employable" story a lot on the internet, but in the large organization where I work I, in my mid-20s, am conspicuously very junior. Most of my coworkers are middle-aged, most of the program management are getting into their '50s, as you might expect of someone in a role seen as senior.
I work at a mid-sized B2B telecom (just over 500 employees), and looking at the ages of my coworkers, we have more 30+ people than not, and there is a very large contingent of 40+ and even some 50+ people here.
It's definitely the kind of company you want to work at if you're middle-aged.
but how many people who are middle age try to "enter" the industry and succeed? I can answer that for you: those who have close friends in power who wish to hire them. As you age yourself, you may see this if you are sensitive to it. We need to separate the two groups, because thrre are two issues here. 1.aging programmers already working in the industry and 2.those who are accomplished in another dying field who decided to/had the good fortune to be able to reeducate themselves in a new field for them--programming. It's the second group that have trouble even getting an interview, and when they do, are often passed up for a younger "junior dev" who is not as skilled. I realize I can only speak to what I've seen here in NYC, but I keep seeing it, and I see it a lot. So are we going to acknowledge it? i hope so. I hope we can find a way to allow people to change paths in life when their path ends, if they are humble and willing to work hard. That is the kind of society I'd like to foster.
Skepticism of bootcamps (and other non traditional paths) is not the same thing as agism. This industry is further along in figuring out the former than others, but you're right that it has further to go. It's just not the same as agism, though.
You are correct, of course. But when someone over 40 has a much deeper understanding of programming in several languages, a CS degree, AND experience from 2 bootcamps, AND at teaching (in 2 bootcamps, at a University, and with private clients) AND has coding experience at a school, with private clients, and one's own side projects in several languages- a linguistics blog, journalism and technical writing experience, and they are then turned down for a junior technical writing role at a company where the tech writers can't code at the same level, I don't know... it is hard to say what that is, isn't it? But yes, I completely understand skepticism of the breadth and depth of the skills of those whose ONLY experience of programming was at a bootcamp. And when that same company makes a mistake in their own assessment (which you politely point out after you are told you are incorrect in your technical writing), and when that same company hires someone with virtually no experience in any of these things as its next writer hire and also for its manager of technical writing, and while those two employees are in their 20s...what would you think? Am I excluding a possible interpretation? "Culture fit"? The candidate we speak of doesn't fit the expected cultural profile in several areas for a tech company. Might it be that in some other form? It is just really tough to say. I realize it stinks to see how blatant ageism can be. It makes all of us feel unsettled for our own futures-- it is also just stupid and embarrassing in an industry that prides itself on being so smart. But we have to get real about it. We also have to get real about sexism and racism. It seems to take more than a village (of women at Google, Uber, Tessla, etc.) shouting it out with lawsuits and news articles. We have not even begun to handle race issues in tech, perhaps because so few can break through. We need to face these things and stop trying to explain them away with coded words like "culture fit" or "updated skills" (when the skills are updated, of course). We need to look around our departments and seriously ask if there was ever a new hire over 40. Then, we can dig into these issues. We have to stop knee-jerk dismissing the stories of those who are shafted by these practices. Yes, it is uncomfortable.
Actually, we all need to grapple with the fact that big corporations are behaving more and more like startups because they can. If Google has a higher standard (as has been reported by Google SWEs who perform interviews at Google right here on HN) for entering SWEs based on their age, then we need to take a hard look at that. Yeah, it's illegal and unfair, but no one over 40 and really over 35 is allowed to be a great "junior dev" - they are only comfortable w over 35 who have been in the industry. The ladder is pulled up at most places for even excellently skilled beginners after 35. One should be able to enter if one has skill at a higher level, but we all need to face that the level one must hit at 35+, as a woman, as a person in any underrepresented category in this industry is much higher than it is for those who are a good "culture fit".
Yes, you make good points. A distinction should be made between junior 35+ people and 35+ people with at least a decade of experience.
But I don't think that's exclusively a software engineering issue. If I tried to become an electrician at 40, my guess is I'd encounter some bias, though probably less than in software.
One other thing: by "BigCorps", I'm referring to things like banks, Wal-Mart and so forth, not technology companies like eg Google.
> One other thing: by "BigCorps", I'm referring to things like banks, Wal-Mart and so forth, not technology companies like eg Google.
Yeah, I'd much rather work at a traditional conservative BigCorp than a Silicon Valley company that never grew up from startup mentality.
If you do want to stay I tech, I'd recommend looking at the B2B telecom sector. It's far, far more conservative then any other part of the tech industry. They're the only tech companies that I've seen ban T-shirts in the office.
I'm working in a B2B telecom and I haven't seen that level of conservativeness, although in general I agree that they are conservative. But it's a wonderful place to work in many aspects: it's stable, pays well, and in general less clients means less headaches and a more focused development.
They don't immediately adopt new technologies, but frankly, nowadays I see that as more as a feature than a bug (although once in a blue moon I wish the delay in finally adopting them, when they have been successfully proven themselves, wasn't so long).
The most glaringly conservative aspect of my current job is its very rigid adherence to process. Again I must say that, having worked in places where it wasn't the case, I'm so glad that process is followed strictly.
The big problem with this job is that I've acquired a ton of domain knowledge that probably won't be useful in another job. This means that I need to keep other tech skills (algorithms, programming languages...) much more finely honed. On the other hand, I've acquired top notch documentation skills.
EDIT: I also can confirm that there is plenty of >40yo people here. Definitely a good place to be when you reach that age, although I'm only in my eearly thirties. I've found also a high level of diversity in general, which is very, very good.
I'd say this is a great tip for a candidate who isn't underrepresented in tech. I just came from an interview at a conservative midwest company that isn't technically a "tech" company but has a huge tech dept. Got to the end of 5 interviews at breakneck speed and with lots of acclaim from the team about my speed and competence...that is until they saw me. Everyone, and I mean everyone in the engineering dept., save one woman (she must be a 20Xer) was firmly within the typical tech demographic. I felt I did quite well despite suddenly being asked CTO-type questions. I was told there would be whiteboard algorithms and questions about the company itself. They knew I'd never worked at a big company with a giant code base before, and yet they were enthusiastic about my ability to contribute-- it had come up and was not an issue. They wanted to fly me out and put me up in a hotel. It turned out I didn't need it because I happened to be there, but they offered. They even talked to me about salary numbers. When I got to the on-site, I got questions more fitting for a candidate with many years' experience with a giant code base at a big company. Still, I felt I answered well. In the end, they told me I didn't answer those questions quickly enough (not correctly enough-- just quickly enough). I'm fairly certain that If I were given the chance to actually work at a large company, I'd know the answers to these system design issues without having to think to arrive at the correct answer. I'd know from experience. If I'd looked like more of a "culture fit" let's say, but still over 40, I think it might have been fine. By the way, the city that this company is in is 82% African American. Its tech department was 0% African American.
I was under the impression that these sorts of BigCorps were actually a better place for the underrepresented and frequently have more diverse technical workforces (along race/age/gender lines).
I just got hired by one in Texas that reflects that impression, which I had before I ever interviewed there.
Java is absolutely rightly derided as the next COBOL because it is. It is the abstract concept of bureaucracy incarnated in code. But that means it will likely follow COBOLs trajectory. A million legacy systems written in it will underpin the central core of a million businesses, being the (entirely unrecognized) most important component of the entire corporate structure bar none. And those systems will need care and feeding in their old age.
"I don't think Java is all that bad, and I can enjoy well-done object-oriented programming."
This is probably the most accurate opinion of Java the language I've seen, one that isn't tarnished by what anyone has seen in any proprietary codebase.
I would rather program in Java the programming language than Javascript any day of the year, even if I dislike the vast majority of popular Java frameworks like Spring, Hibernate, etc.
Yes, I should have made it clear that Java the language is not inherently terrible. And the JVM itself is really quite nifty. It is unfortunately the infection of Java codebases (literally all of them I have seen with the sole exception of short Processing sketches made for graphical effects) with a mindset of design patterns as lego bricks used to build applications. Java did have a rough start though, there was clearly an edict at Sun to invent a nomenclature which deviated from any terminology commonly used by Microsoft which operated only to its detriment.
I think the JVM itself will be Java's saving grace - languages like Scala and even Clojure now are gaining huge popularity that not only leverage the JVM and existing ecosystem but have the ability to rapidly advance and abandon Java's warts. So it's not like COBOL in that regard. Because of the power of the JVM ecosystem I think even Java's glacial pace of adopting new features will be enough to keep up for many years or even decades to come.
You are correct that I have never written COBOL (or JCL for that matter), though I'm not sure why what I said would indicate such a thing. I have seen COBOL and working COBOL systems. They are absurdly verbose. That feels like a hyperbolic understatement, really. Everything is very structured, in the nature of micromanagement in organizations, formed in that way in order to intentionally forbid flexibility. Is the COBOL I have seen 'old fashioned' perhaps? It was well over a decade ago, closer to 2, since I've looked at any. Perhaps there is a 'lightweight' COBOL?
Find a niche that rewards experience in something other than code. This could be non-technical (e.g. "business"), or it could be something more deeply technical (e.g. scaling, machine learning, search, etc.) To some extent, the older you get, the more this happens, naturally. But you can and should make strategic decisions about where you choose to devote your attention.
The important principle is that you should devote your learning time to things that are more likely to survive. A good way to do this is to pick something that has been around for a long time. Knowing how to write an optimized linux kernel driver is far more long-term-valuable than, say, a Javascript framework. Knowing how to do quantitative marketing is even more valuable than that.
The absolute worst thing you can do is to chase the new shiny every year. If you do that, you will never be more experienced than the most junior member of your team.
Why would JS be less long-term-valuable? It's only 4 years younger than linux, it's more common than linux and has a much larger community (especially compared to the linux kernel driver one). I don't see either going anywhere in the next 20 years.
It was born as a 'just good enough' hack, jammed into a static document presentation system into which interactive application functionality was shoehorned with pain points at every turn. It currently writhes in a morass of dependency hell, sprouting a hundred duplicate efforts of trying to soften those pain points every day. And it managed to get so big because the W3C continued, year after year, to obstinately refuse to acknowledge the web as an application platform until very recently.
But, they did acknowledge it. And they're now making design decisions to facilitate the web as an application platform, rather than intentionally trying to make application development as difficult as possible to dissuade it. So now we've got WebAssembly and tomorrow or the day after we will have any language anyone wants to use being used. In that arena, Javascript will get pantsed and laughed out of the room. It will probably happen with pretty amazing speed, as there are legions of developers who have been holding their breath for this for 20 years.
Although you've been downvoted, I think your question is fair, so I'll try to give it a fair answer.
In this discussion, when we talk about value, I think it makes sense to look at value in the sense of how valuable a skill is to the longevity of your career.
In that sense, JavaScript has some upsides - it's everywhere, and will likely continue to be everywhere. There will be lots of demand for JavaScript development.
But because JavaScript is everywhere, tons of people know it, and tons of people are learning it. So although there will be lots of demand for JS development, if you're a JS developer, there will also be a ton of people offering a skillset that is broadly similar to yours.
As you mentioned, the demand for something like Linux driver developers is tiny in comparison to the demand for JS developers. But the talent pool is relatively tiny, too. So it might be easier for you to differentiate yourself because when an employer is looking for someone with your skillset, they're not going to have to wade through hundreds of resumes from people who look pretty qualified.
In general, I think it's most valuable to specialize in solving a certain type of problem, where programming just happens to usually be the best way of solving it. It's often easier to sell yourself as a solver of specific kinds of problems than it is to sell yourself as a generalist with experience in JS, HTML, CSS, etc.
It's true that differentiation is a factor in career longevity, but it's not the point I was trying to make, nor the one that I would emphasize. The true advantage of learning how to do kernel development (over, say, a Javascript framework) is mostly that you're learning a technology is likely to be in demand in 20 years.
Given how much JS development thrashes, it's a pretty reasonable bet that whatever you're learning this year will be out of fashion next year, and irrelevant in five years. That's the high-order bit, when you're thinking about your career.
Even for something as "narrow" as linux kernel development, I can pretty much guarantee that someone will want hire you in 20 years, so long as you are competent. I can't make that guarantee for most technologies.
I changed it to "Javascript framework" to stop triggering the JS devs here, while making the identical point: if you specialize in a technology that was invented last year, you are taking a big risk that it won't survive. If you pick a technology that has been in active use for over 20 years and is currently popular, you are taking less of a risk. This is harder to do, but like many things that are hard, the reward is higher.
I really wish it were possible to make reference to JS in a less-than-glowing light without being downvoted, but alas. Substitute any other brand-new technology for "Javascript framework" if you're having difficulty seeing the argument.
I did not downvote, but I do think JS is a bad example. JS has been active for over 20 years and is currently popular. Sure, new frameworks are popping up and everybody rallies around "the latest", but come on, it's not like Java and C# are written in stone.
I wouldn't use Java or C# for that comparison, either (though
yes, it's a safer bet that Java will be popular 20 years from now -- Javascript has only become popular as a language in the last 5-10 years, whereas Java has been popular since the 90s.)
But would I bet on Javascript over (for example) C? No way. Any new developer would be wise to learn C, even if they completely ignored Javascript. And I don't need any technical details about the language to make that call.
You have to be better than you were at 25 (more productive, making fewer mistakes, able to take on greater responsibilities). You have to be better than you were at 30.
You don't have to be as actively sought after. You should be staying at positions longer - 5 years, maybe even 10. (Note well, however: By this point, you probably have seen several toxic environments. If you're in one, don't wait - get out. Life is too short to put up with it.)
I have a file where I keep track of headhunters that I think are worth their salt. I'll use it if and when I feel like it's time to move on.
Understand business needs. Be able to communicate. Be upstack: infrastructure, DNS, SSL, etc. Go deep on security: many concerns cut across many languages, but if you're a language/framework of the week developer, you're too busy learning the same thing over and over to have that depth, which businesses desperately need.
(I'm 40 and my current role is with a small company where I implement solutions rather than have a title)
Security is one of the few cross-discipline, cross-domain specialities where it is possible to be a reasonably good domain expert and still have a good coverage across other domains. The fundamentals don't change. (And I say this as someone who's been immersed in the field for 25 years, so of course I'm biased.)
There are few other domains that can offer the same level of constant demand.
The beauty - and the depressing aspect - of security is that maybe 10% of security is about software. The remaining 90% is all about what is between people's earlobes. To become good at security, you'll need to learn how to explain extremely difficult and often subtle concepts. And you'll have to do that for both technical and non-technical crowd. That's a fantastic and continuous trial by fire. It's also lots of fun!
Bonus: because everything is a tradeoff, you really can't avoid the engineering approach. Teaching the concepts and reasons for tradeoffs to less senior developers will be part of the job specification. Fun.
> language/framework of the week
To quote something I have often stated in our interviews - there are only four programming language families. Everything else is syntax.
To be perfectly honest, I don't know which bucket I should use for Prolog. It's supposedly logical, declarative and functional at the same time. I've never managed to understand it, despite trying.
And for the record: perl in basic form is imperative. With the introduction of "bless" keyword it crosses over to object-oriented domain but following the syntax is not necessarily straightforward. [I've spent a non-insignificant number of days auditing OO-perl. It's not a pleasant experience.]
Those are more dimensions than buckets, and not very orthogonal ones at that. In particular there is strong overlap between declarative and functional language features (you could argue functional is just a special case), and less strong overlap between imperative and OO languages, and OO and functional. OCaml fits pretty comfortably in all four of those categories, when you want it to.
If I wanted to jam languages into 4 categories, it would probably be the Algol, Lisp, and ML families, plus All Those Other Languages. :)
I reckon imperative and OO are almost identical; if you don't have objects, you use function pointers or discriminated unions instead and end up with something very similar. OO is a design pattern that often has language support. And I could make a similar argument that functional is mostly just a style of coding, where some more restrictive rules are followed - but it also depends on a few specific language features, e.g. garbage collection and possibly tail calls. You can get by without pattern matching and first class functions, but they make life much more pleasant.
Declarative vs imperative is more interesting: what vs how, building descriptions of problems rather than chains of calculations or lists of steps. I don't think functional style is strongly related to declarative, except in the very low level sense that a functional program doesn't necessarily have a sequential evaluation semantics. But that's increasingly true of seemingly imperative languages also.
The ML family tend to come from a research background, have a more rigorous approach to typing, solid type inference, and very differently flavored syntax. MLs are functional (first-class functions, expression-orientation), whereas the Algol family in the shape of C, Java etc are mostly imperative. They tend to have nice pattern matching facilities. There's more, but that's a lot of it. A lot of these features have been transplanted into languages that are basically on the Algol tree, so it's often a bit fuzzy these days.
I'm not quite 40 yet (36), but part of what I've done is the specialization mentioned in other posts here (in my case, distributed systems with a focus on communications tech), and I've also cultivated my "product sense" to the point where (as an individual contributor) I'll often define and design a product and how customers will use it, in addition to doing the actual implementation. In that sense I have a little bit of breadth; I'm not "just" an engineer, I can also address the customer needs that lead to building a product, and then later refining it.
Understanding customer needs and translating that into product definitions is something that will likely never go out of demand, and is needed in industries outside tech. And if demand for distsys goes out of style I'll just learn something else. I've already kind of done that, having cut my teeth on embedded systems, followed by a short stint in mobile before getting to where I am now.
Judging by what I see around me, I don't see the strategy being any less effective in 10 or more years.
I started at 21 and somehow just kept getting older.
More seriously, having had a look around my cohort, there aren't that many people who've left programming altogether, and those that have have done so for personal reasons. Generally people have moved "upwards" and acquired management track positions. Small companies are good for this - because it's so flat you can easily get a high-ranking job title which you can then leverage into the next job.
Look "up". Look at the older and more senior people in your organisation. Maybe even directly ask them about careers. Recognise that if nobody around you is over 30, you're either in a very unusual place like an SV startup or you've wandered into Logan's Run.
Apply to a government job. There is less ageism in the Gov than in the private sector. At least in my country were you must do pass a very difficult and competitive contest.
Unfortunately, at least in the US, pay is not very competitive. Even with upward adjustments for cost of living in more expensive markets, many of the people on here with SV or SV-like tech jobs would end up taking a pretty large pay cut to work for the US government. (But it's of course a great option if you're in a bind and your alternative is no job at all. Or if you're a civic-minded individual who does it out of a desire to improve the sad state of our public services.)
One way to make it past 40 in software is continue demonstrating that you're learning, creating, releasing, and share it publicly like you may have in your 20's.
