Programmers: Before you turn 40, get a plan B
improvingsoftware.com
improvingsoftware.com
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.
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.
As a several year veteran in the government contractor space and from personal experience as a configuration manager, I strongly disagree this this. I've seen poor and mediocre programmers survive as programmers well toward retirement age. Part of the reason is that programming isn't the only skill that they provide. They provide domain knowledge on the systems which the gov (mil and civilian) rely. Then us poor sods have to clean up after them and clean up after them, and hold their hands on radical new ideas like object oriented programming. I could really rant on this topic if I wanted to.
Another perspective: I mean, how many coders do you know that make it through a few years working who have NOT developed some significant domain knowledge?
When you talk about government and government contracting you are discussing an entirely different world devoid from reality.
Of course, I may be biased since I work as a contractor.
I'm not suggesting contractors beat their children. I am saying that if one wants to move up within a government contracting company they will reach a point when they will have to push a course of action that is not in the best interest of the government at which point the individuals and company are indistinguishable.
http://thedailywtf.com/articles/up-or-out-solving-the-it-tur...
FWIW, I think there's enough people in this audience that wouldn't be happy holding on to a job they aren't particularly interested in keeping up to date on, simply because they have the domain knowledge to make them "safe". I could be wrong though.
* The higher-up the position, the longer the curve. Changes tend to occur much more slowly at the top. For example, a basic “refactoring” of a department’s teams could take well over a year to implement.
* The greater the skill, the shorter the curve. Ambition and skill go hand-in-hand, and ambitious individuals tend to want swift changes, and quickly lose motivation when these don’t happen.
* The larger the company, the shorter the curve. Large teams are generally not receptive to ideas from the new guy, leaving a large part of contribution (i.e. past experience) wasted. Furthermore, promotions are often based on tenure, not skill.
* The smaller the company, the longer the curve. Smaller companies, on the other hand, are more receptive to change, allowing one to contribute past experiences for a long while.
* The less skill-demanding the company, the significantly longer the curve. Not all companies need top talent. For example, the company who needs only maintainers of an ancient COBOL application might be best fit with curves that are closer to the value convergence."
Notice what happens when you're very skilled in a large company?
In the 80s and early 90s, affordable computers existed but there wasn't so much you could do with one. The list of activities looked something like:
1) Play Choplifter 2) Play Loderunner 3) Learn BASIC
Programming was a natural thing to attempt to do since there was little else you could use a computer for at that time.
- A menu-driven File Management system because I was sick of typing commands.
- Checkbook management system to make balancing my account easier
- Heating & Cooling timer thermostat control
- More stuff I can't remember any more
Oh, by the way, they were all written in BASIC!
Your implication is exactly backwards, from what I've observed. People who learned programming as a kid for the joy of it are much more likely to be good programmers. People who went into it for job training are much more likely to suck.
I agree with you, but I also started learning to program with a Commodore 64 when I was six, so I'm probably a bit biased. :)
Software and technology more than ever is everywhere and becoming so deeply embedded in our lives that the demands for great programmers shall continue to grow to feed those needs.
It surprises me to read this, when most other times all I seem to read about is how a "shortage of engineers" exists in the world.
While I've always loved programming, before I even got a PC (14 years ago, loved the idea so much that I started reading a book about programming in Basic before I had access to one) ... I really hate the industry (at least the local one).
Life would be a lot easier for me if programming was a hobby in my spare time. But as it goes, I'm doing a lot of work on projects that I don't like, and when going home I don't have enough energy left to work on things I love.
I don't think I'll ever give up programming though.
Never underestimate the stupidity and shortsightedness of a bad manager.
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? ;)
That said, while I appreciate your sentiment, I know in my heart that the author is right. All of my friends from college have moved out of programming. Many have left the industry completely -- and we're not even that old! The bottom line is that there's little or no cost advantage to hiring an older coder, when I have t-shirts that are older than the most popular development environments.
Every once in a while, some young geek chimes into these conversations with the observation that one needs only "keep up with technology" to stay relevant in the industry. But even ignoring the fact that "keeping up" is usually easier said than done, the economics just don't work out. My friends who went to medical school are finishing their residencies and starting in private practice; my friends who went to law school are making partner. In most industries, you're just beginning your career when you're in your early 30s. In software, you're already old enough to be a conversation topic.
It is like being overqualified for a job: You have all the skills needed yet your motivation and personality is questioned.
I realize that good companies recognize talent, and that überhackers with brand name projects behind them will always be in demand, but sadly the world is made up of different realities.
Even the "keep up with technology" people know in their hearts that these articles are correct. Everyone knows programmers have a half-life, they just are in disagreement about when it kicks in. Nearly everyone would be surprised to discover a 60 year old programmer who was still gainfully employed. 50 is really pushing it, 40 is pushing it, and 35 is starting to push it. In contrast, nobody would think it was weird to see a 40, 50 or even 60 year old doctor or lawyer.
That's half the story, but it's a big part of it.
The other half is that it's an area with gradual drift out & little drift in.
That half needs some explaining but it seems like more of a young man's game then it is. It's easy to get behind. If you're out for 2 years, it's daunting to get back in. The opposite is true for some domain (like medicine). You get very little drift in to the field (more programmers become HR people or sales people then the other way around). It's a first career, not a second.
My point, I suppose, is that your experience must still count for something within certain domains. Right? Or am I wrong on that, too?
I think you'll find that in industries where safety & reliability is critical, experience is always a great benefit for the applicant.
I wonder how much this is to do with the relative newness of programming as a profession. Medicine and law have had a very long time to develop systems to train the young, then identify and reward the knowledgable and talented. Perhaps in a few decades 20-something and 30-something programmers will be regarded in much the same way as their law and medicine practising counterparts.
Also, programmers who have been working for >30 years (who started before the mid-late 70s) didn't have the option of learning to program at home, on a PC. PCs caused the number of new, but not potentially good, programmers entering the job market to spike.
A dot com crash and several cube jobs later, those same folk are living in better homes and driving luxury suvs while I am pondering how I can escape the hell that is a modern day software cubicle job....Guess the joke really is on us.
The other thing about new technologies in general, and Rails in particular, is that 2 or 3 years of experience doesn't really mean much because the evolution is so fast. There's lots of Rails lore out there on the web which is completely out of date, and if you're not willing and able to dive into the code yourself and design your own experiments you're going to make completely incorrect decisions about how to design your app and write your code.
1. The "geezer" with 10 years of C++ probably wants a lot more money than the guy straight out of college. If the company both needs that expertise and can afford the premium then they will definitely go with him, but if money is an issue they may be happy to take the younger guy for lower pay.
2. The guy with 10 years of C++ may be more qualified than the hiring manager. If the manager is focused on the needs of the company of course this is no issue, but if that manager is some middle management person in a large organization who is worried more about his little fiefdom then the company as a whole, he is likely to avoid any candidate that might overshadow him.
I was a fresh graduate once. I remember my productivity less as "60% of that of a twenty-year veteran" and more as "It is a miracle that they allowed me into the room for a purpose other than to empty wastebaskets, to say nothing of permitting my code in shipping products".
My product's code, particularly the parts of it which were laid down earliest, is so bad in some points that I wouldn't pollute a repository with it if I were rewriting today. Oh, God, the print logic. I can quote one line out of that file by memory:
// Abandon all hope ye who enter here.
I know a developer who was learning two new programming languages and started writing serious production code within three weeks of starting his first job post graduation. He took over maintenance of a complex application and rewrote it in a new language. He managed to double his salary 18 months into the job. There risk in hiring someone unproven, but you can buy that down quickly.
One of the better examples of this is helping to debug someones program. Now I frequently hear, I was trying to do X, it almost works, but it's also doing Y, and I will say ok you made a mistake in this area. It's not just understanding code, but also understanding the typical mistakes we make. Tracing down an off by 1 error is something everyone learns, but they don't teach it in school.
The first 100K lines or so are easy and somebody with talent who is fresh out of school is going to get to the finish line at least as fast as a 10 year veteran. The real test is the next 100K lines of code which the experienced designer is going to breeze through while the novice is about to learn an important lesson: Writing large programs is much harder than writing small ones.
In a higher level language you get a lot of good design for free. For example nobody has to worry about GoTo-spaghetti-code any longer.
Plus there's experience with the toolchain. Experience with the codebase. Knowing how to play "the game" of meetings and reports.
Suppose you pay a fresh college grad 50k. 70% more is 85k. But 70% less than 85k is 25.5k.
So you would definitely pay the experienced guy 70% more.
I know this is just an example, but 10 years is nothing. Some of us got into this stuff out of high school.
Where did the time go?
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.
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.
When the posers and BS'ers meet their makers, it's not necessarily a bad thing; I prefer to call it "industry Darwinism".
Not my experience. I (and almost every other programmer I have ever met) have had some control over everything I've ever worked on. Perhaps this is a self fulfilling prophecy: if you don't think you have any control, then you don't.
"Presumably the value most developers out there deliver is producing a coded up version of someone else's specification."
Not my experience either. At least on this planet.
If anyone else ever produced a specification rigorous enough for me to code from, I could die happy.
Or you've tried to get some control, and have had your hand slapped away. And then realize the part that you don't have control over is the crux of the product's value proposition, and that it is a bad value proposition. Having control of the how isn't going to make it valuable enough, because it doesn't solve the right root problem. If you've ever tried to push a certain direction, only to have people respond "that is management's decision, not yours," that's what I am referring to. Perhaps you have never experienced that.
"If anyone else ever produced a specification rigorous enough for me to code from, I could die happy."
That's not quite what I meant. My point is that, in a large number of development shops, this is the way people deliver value. Their manager and the organization he represents is the customer, and often times they already know what they want, even if it is the wrong solution. It comes in the form of a specification, even if that is badly written. The value they bring is their technical skill set, such as it is, because most of the other decisions regarding the product have already been made by the time it gets to them.
I'm not ascribing this method of delivering value to you and those you know, nor to I and most of the programmers I know. I'm ascribing this to the people in the stories they and I tell of the other programmers we've met who operate this way: offering technical skills, and otherwise having faith everyone else will figure out the customer value part. Some are getting Darwined, as people find out they don't even provide what they claim to offer, but enough people out there find good value in a cog.
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.
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.
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.)
A good reason to live in a tech hub, if you want to be able to change development jobs without changing residences.
I would like to point out that these don't simply fall out of the sky. They are something you sign up for voluntarily (at least in the civilized world.)
You can live an excellent single life as a software developer. $100k for a single guy is good money.
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 just now coming into their own in the industry.
Specialization is not free; it decreases flexibility, and would seem that it would decrease cross-pollination of ideas from different areas of knowledge. It increases income, for sure, but also increases the attendant risk that people won't have need for an X specialist right at that moment, or at least no one you would want to work for.
I'll grant that generalization is not free either. Someone who really needs an X specialist will pay top dollar, because the supply is likely pretty low. And people may not trust a generalist to go and implement some specialized X performing application.
I think there are opportunities and attendant risks for both. I really don't think either one wins outright. But, I'll be happy to listen to words of wisdom you might have on this.
Personally, I am a database specialist. I do have skills in other areas (I do python coding as a hobby and I can write C# code that at least works), but my strong suit is definitely in databases, and even with databases I focus on MS SQL Server and Access with just a little experience in some others.
I personally chose to do that because databases appealed to me and by specializing I could gain a depth of knowledge that very few generalists can. In terms of careers this limits my options somewhat, but it means that within my particular domain I can out compete most others. When the company needs a generalist that can do a lot of things, I am probably not their best choice, but when they need someone with a deep understanding of SQL Server and relational theory then I am a good candidate.
Its all about trade offs really.
Deleted comment
But the big scary force in this article is, "over 10 years, your C++ experience makes you progressively more expensive and less attractive to a Ruby shop". That's true, if all your 10 years were about was C++. C++ is a distinctly dumb thing to build a career around.
For that matter, so is Ruby, Rails, Python, and everything else that's popular today.
In ten years, everyone will be using Blub, and badmouthing those dumb ol' guys who were slogging around in Ruby. It's the one thing in life I can guarantee.
Most recruiters and big company HR departments are among the biggest destroyers of meaningful language there are. "Keyword compliance" is just another of the forces trying to dumb us down and turn us into automaton neurons in a big brain, exchanging and processing signals we don't have any inkling of.
Just my two cents, but I think you might be doing yourself a disservice by dumbing your resume down to their level... Unless the type of job you're looking for is just a cookie-cutter "latest pet framework" position.
Yoga has been helpful, but I'm wondering how long I'll be able to cope.
- yoga (which you've got covered)
- a kneeling chair does wonders for posture
- placing your monitor at the proper height (eye-level is 1/2-1/3 from the top of the screen otherwise you tend to crane your head forward and downward)
- stepping away from the screens regularly (set a timer to remind you because it's easy to blow this one off)
- eye exercises (especially this one...alternate focusing on the tip of your nose and focusing on a far distance)
Good luck
Ubuntu includes an application to enforce breaks by locking your screen. I have tried it. Works.
Buy one of these (way too expensive) keyboards:
http://www.kinesis-ergo.com/images/freestyle-solo_690x375.jp...
Then build one of these out of a cardboard box and duct tape:
http://www.kinesis-ergo.com/images/solo-ascent-90_512x390.jp...
For the vertical layout, the spacing of the keyboard prevents wrist bending: the two sides of the keyboard are roughly shoulder width apart. When you aren't typing, the natural thing to do is put your hands in your lap.
"Of the software-centric industries, what percentage of employees are actually writing software? What percentage of software developers do not work in these industries."
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.
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.
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.
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.
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.
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.
The real question is whether the people who "drop out" of the statistics still wanted to be "programmers" at 40.
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.
As noted elsewhere in these comments, the ability to pick up a new language is not really the critical factor in experience.
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.
This is helped by a mindset of taking the initiative for your own education, and never stop learning.
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?
I have been slow to retire vim. In fact, I keep learning new things that make my work easier (like :arge filename --- the e means it's like :e, to edit a file, but it also adds it to the arglist, so you can move back and forth the list of files with :n and :p; and :tabnew, ^PgDn and ^PgUp give you tabs and switching between them).
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.
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.
If they're "too expensive" to hire doesn't that imply that their services are in demand?
Deleted comment
So specialize in something where those years of experience accrue to your benefit. 10 years of image processing experience will make you an industry thought leader, as would 10 years of cryptography or 10 years of compiler backend design. We aren't running out of applications in these fields.
Come on now, what basis do you have to say that someone who is a generalist is unable to provide value to people through the software they write? Do people need to be excessively specialized to make something people will pay money for?
And for that matter, I could see the generalist programmer fairing better, because they don't lose the general theory things are based on while diving incredibly deeply into a narrow body of very specific knowledge. If the job/labor/consumer/whatever market presents some new area of need, they're in a better position to go learn and capitalize on it.