Disclaimer: I didn't read the full article. I can't stomach these types of "career strategy" articles anymore. This approach to life in general is very misguided (maybe less so if you just want a career to fulfill other goals), but for those who want to pursue a more idealistic life, just pursue your passions. Plan B is being an improv comedian. Plan B is writing the great American novel. Plan B is traveling the world as a war correspondent.<p>I left corporate world precisely because I felt "planning my career", as I was encouraged to do, was an absolute false way to live (for me). I couldn't reconcile the absurdity of it with the severity of the consequences if I didn't do it. But the consequences are all socially constructed, and they go away as soon as you change your mentality.<p>When I think of my heroes, I don't think of people who've hedged their bets here or there - they just did what they felt they had to.
This reasoning doesn't take into account the fact that a lot of people are very bad at programming and get tired of doing something they're very bad at. We have a fair number of bad programmers in their twenties, few in their thirties, and probably none over 35. It isn't because they get better. The only middle-aged programmers we have are absolutely solid.
If the geezer with 10 years of C++ experience showed a capacity to rapidly learn a new language / framework, I'd hire him every time. Those 10 years of C++ experience taught a lot in terms of general understanding of programming, best practices, how to "think" like a programmer, etc. (or at least one would hope; it varies, of course). That is far more important than a few years using an extremely high-level language.<p>I think about it this way: I am supremely confident that I could know all I need to know about Ruby/Rails to do just about anything within a few months of working on an honest-to-god project. I'm equally confident I wouldn't know a fraction of C++ in that time. As our tools continue to become higher-level and more acutely focused, they become easier and easier to grok. The learning curve of a language with C++'s history vs. a new-shit-on-the-block web framework? Forget about it. You can write a blog in 10 minutes, remember? ;)
OP glosses over one critical truth: programming is not just about delivering code, it is about delivering <i>value</i>.<p>In spite of what many of us technologists may think, customers and employers do not purchase "software", they purchase the benefits that software delivers. These benefits come in many forms, and it's just as likely that they come from solving general problems as well as solving technical ones.<p>If someone at any age complains about their difficulties securing work, it's not necessarily because of their technical skill set, it's because they're not delivering the value their customer covets. They need to find out what their customer needs and deliver it, whether that means brushing up on their skill set or not.<p>When the posers and BS'ers meet their makers, it's not necessarily a bad thing; I prefer to call it "industry Darwinism".
By the time you turn 40, you may likely have a mortgage and family. Packing the family up and selling the house to pursue a more challenging development job in another area is just not feasible, especially when your spouse has her own career. The "Plan B" suggestions given by the author are good for people in this situation. A few more are teaching software development and writing about technology as a journalist.<p>Most software in the field today (80% is the figure I read - trying to find the article again) takes user input from a screen, queries a database, and sends results back to the user. After developing enough systems like this, you realize only the technologies are changing, not the problems solved. Keeping up with the latest tools does not change the dull repetition of this reality so you can easily lose incentive to keep up. And, frankly, I'm not sure companies need to pay someone with 20 years experience to do such mundane development.<p>Interviews for my last couple of employers centered more around growth in the organization, ie. understanding business processes, the business' industry, and organizational dynamics, not on technical knowledge. I think there comes a point when organizations begin evaluating a potential employee on potential to grow in the organization rather than grasp of functional vs. imperative paradigms, etc.<p>If staying a developer is what you really want, then it's probably worth learning another problem domain. Perhaps mining biological data for patterns, etc. (Heck, despite advances in neuroscience we can't explain why a stroke causes memories to "move" to another set of cells in one patient but are lost in another patient. There are plenty of problems to be solved.) Anything that makes the field fresh again. (Of course, you may run into the same problem I stated in paragraph 1.)
This logic is so broken. Languages and dev platforms may change every 10 years. C++ may get stale. But image processing, or compression, or security, or low-latency high-throughput congestion-aware network protocols, or what-have-you don't.<p>Just don't pick things to specialize in that are guaranteed to date themselves. People who did program transformation masters theses in the mid-90's are <i>just now</i> coming into their own in the industry.
Sigh. Over 40 geezer checking in, but because I spent my 20s pursuing a music career, and then a number of years in QA, I've really only been doing pure software development for about 4 years. The problems I've been encountering these days mostly center on the physical demands of the job (typing and sitting) -- joint pain, back pain, tendinitis, etc...<p>Yoga has been helpful, but I'm wondering how long I'll be able to cope.
I think there are some other questions that need to be asked here. I'm not sure exactly how to phrase this:<p>"Of the software-centric industries, what percentage of employees are actually writing software? What percentage of software developers do not work in these industries."<p>I don't know the answer to that, but for some reason I think it's well under 50%. It tends to (on HN anyway) get presented as the coders & management. But (IMO) that's too simplified to mean much.<p>Programming makes sense as a starting point. It's a relatively straightforward, transferable & acquirable skill set. On the other hand, things like account management, or sales may require the kind of skills you need experience to gain & are hard to develop intentionally.<p>Also, I think it's relatively easy to shift from coding to something else organically, but not the other way around. If you are a programmer that ends up making software for the agricultural industry , you may pick up all sorts of skills & knowledge that make you useful in other areas. If you enter that industry from another end (even if you are very close to the software), you are unlikely to become useful as a programmer. At least not without intending to.<p>You wouldn't be surprised to hear this story: CS degree at 22, worked as a developer of farm management software for 5 years >> a (software/technology) consultant in agribusiness for 5 years >> a manager/executive/account manager/marketing person etc. for irrigation supplies manufacturer >> something else.<p>You would be somewhat surprised to hear the reverse, someone with 10 years industry experience leveraging that to create software for that industry. It's not impossible, but it's worth remarking on. It probably means that either the person was a programming amateur that went pro or that they actively decided to retool themselves via a path of quite a lot of existence.
What ever happened to the view that some programmers have a capable productivity that is entire orders of magnitude over others?<p>I think most employers just look at keeping expenses to a minimum. This means ruling out the concept of pair programming, because why would you consolidate two into one (even temporarily) when you have a brick and mortar mentality to construction that points to keeping everyone busy? And most importantly, young employees need to pay their dues. That means lower salaries for a while, and toleration of extra abuse.
I wonder how accurate those statistics are. For example a dozen years ago I was called a programmer, now I am called a project manager, but I still work in software in the same group for the same employer - about as good longevity as you can get. It may be that seniority leads to job relabeling that misrepresents the true situation.<p>The real question is whether the people who "drop out" of the statistics still wanted to be "programmers" at 40.
Hiring by resume keyword is good only for recruiters, internal and external.<p>Most jobs [citation required] are found through networking. My advice is to make that your plan B, if you feel you need one. Network all the time.<p>As noted elsewhere in these comments, the ability to pick up a new language is not really the critical factor in experience.<p>The value of experience includes 1) knowing what not to build, that is, avoiding building the wrong thing 2) knowing which approaches don't work, or avoiding building the thing wrong 3) being able to pick up the technical parts of a project thoroughly--the language, code, design in good time.<p>This is helped by a mindset of taking the initiative for your own education, and never stop learning.
Does anyone still think it really matters which programming language a developer has experience in?<p>It didn't take long at all after working full time as a developer to realize that software development is much more comprehensive than simply knowing a language. Shouldn't we all be able to create software in any language after a short ramp up period to learn the new language?
In other words, if you want to be a programmer all your life, become an entrepreneur.
<a href="http://friendfeed.com/akkartik/5ab60c50" rel="nofollow">http://friendfeed.com/akkartik/5ab60c50</a>
<i>The industry turns on a dime, but is slow to retire proven technology.</i><p>I have been slow to retire vim. In fact, I keep learning new things that make my work easier (like <i>:arge filename</i> --- the e means it's like <i>:e</i>, to edit a file, but it also adds it to the arglist, so you can move back and forth the list of files with <i>:n</i> and :<i>p</i>; and <i>:tabnew</i>, <i>^PgDn</i> and <i>^PgUp</i> give you tabs and switching between them).<p>It seems inevitable that the day will come when the Eclipses and IDEAs of this world are more productive (some say it already has), and when it does, I won't be up to speed to make the switch. I don't think typing support is critical for understanding problems and solving them, but it helps.
Has anyone considered the possibility that maybe the workhorse technologies in software development have begun to stabilize? C, C++, SQL, Unix etc. has been around for some time. Java and .Net aren't going to go away anytime soon. We may yet see some disruptive changes in Web development, but I doubt whether the basic Javascript/HTML/CSS scheme, or PHP/Python/Ruby set will become obsolete anytime soon.<p>My plan is to ensure that I can always deliver valuable software and maybe even create some that I can own. A lot of my friends are doing their MBAs - I just don't think that route is for me.
I just found the same phenomenon in science career.<p><a href="http://news.ycombinator.com/item?id=650898" rel="nofollow">http://news.ycombinator.com/item?id=650898</a>
I have a problem with the idea that all the C++ veterans with 10+ years of experience are priced out of the market.<p>If they're "too expensive" to hire doesn't that imply that their services are in demand?
There is one more fundamental reason. When you getting aged you have less time to stay tuned with all changes in your field.
Of course, if you have a contract to maintain some old system, or playng a key role in some long project with solid finance - that is ok. But on the field motivated younger guy will easily outperform you, because you have many things to do as an adult. You simply cannot spend days and nights with laptop.
So, there are two obvious directions how to reuse your experience - project management and work as a system architect. But these positions are rarely vacant, so, you probably should start your own project or a joint venture.
There is no use to try to compete with younger generations on their field (coding). It is much better to reuse your own experience and use thier energy, naivety and enthusiasm.