
Programmers: Before you turn 40, get a plan B - jerryji
http://improvingsoftware.com/2009/05/19/programmers-before-you-turn-40-get-a-plan-b/
======
cglee
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.

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.

~~~
SapphireSun
Thank you! I've felt exactly this way. It's rare that someone expresses it so
well.

------
dkarl
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.

~~~
blogimus
"The only middle-aged programmers we have are absolutely solid"

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?

~~~
pmorici
That's in government though where the contractor is in many cases above all
trying to fill seats to make sure they can bill the maximum amount of hours.
They just call it "domain knowledge" to justify to anyone that might question
why they are keeping someone who is bad at the job around.

When you talk about government and government contracting you are discussing
an entirely different world devoid from reality.

~~~
timwiseman
While I cannot fully disagree, I would like to point out that a great many
government contractors take their jobs very seriously and do very good work.

Of course, I may be biased since I work as a contractor.

~~~
pmorici
Sure at the individual level there are plenty of people who do good work but
I'm referring to the companies themselves. A government contract company's
only real goal is to get more contracts in terms of numbers and dollar amount
and run them in a way that maximizes profit. A contract companies success in
the government realm has little to do with actual performance and a lot to do
with salesmanship.

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.

~~~
timwiseman
You have a certain logic, but all I can say is that I have not witnessed it
myself after working now for 2 different contractors. Of course, in both of
those cases everyone in my immediate management chain was, like me, a former
military officer.

------
tdavis
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.

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? ;)

~~~
timr
I'm that "geezer". Coded in C and C++ for over a decade, and now I'm working
in the magical world of Rails, where I get to watch 20-somethings rediscover
the value of old ideas the hard way. (Given the average comment thread on
Hacker News, and you'd be excused for wondering why _anyone_ ever used
compiled languages or static typing. Silly dinosaurs!)

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.

~~~
menloparkbum
_That said, while I appreciate your sentiment, I know in my heart that the
author is right._

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.

~~~
netsp
It's a bit early for these comments. There aren't that many programmers in
their 50s because there wasn't as much need for programmers in their twenties,
30 years ago. Demand for doctors has been more steady.

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.

~~~
gaius
It depends. You could be out of Unix or C or Oracle for 2 years and come back.
It's only "front-end" technologies like Flash, Rails, PHP, AJAX that suffer
from the rapid churn and the latest thing when you come back didn't even exist
when you left.

~~~
netsp
I wouldn't really know personally, but my reasoning was that not only
technology moves, you forget or lose the feel.

------
edw519
OP glosses over one critical truth: programming is not just about delivering
code, it is about delivering _value_.

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".

~~~
azanar
For the sake of imagining someone working at an employer where they have no
real control over the direction of the product, what value do they bring other
than their technical skill set and analytical ability? Presumably the value
most developers out there deliver is producing a coded up version of someone
else's specification. Outside of having enough business acumen to know when to
shut up before the management threatens your employment (if remaining employed
is important enough to you), what else is there?

~~~
edw519
"...they have no real control over the direction of the product..."

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.

~~~
azanar
"if you don't think you have any control, then you don't."

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.

------
bpyne
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.

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.)

~~~
asciilifeform
> you may likely have a mortgage and family

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.)

~~~
tybris
Voluntarily? More like instincts & hormones.

~~~
embeddedradical
voluntary. you don't need to get permission/contracts set up with the
government/people to love (see "free love" on Wikipedia), and you don't need
to take loans from banks (see renting vs buying articles, especially 'is
renting throwing money away?' or something like that from earlier in the week
on hacker news). // free love advocacy: complete.

------
tptacek
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.

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.

~~~
azanar
I asked this elsewhere, but I'll ask it again here, and I am being completely
sincere. Why pick things to specialize in at the expense of other things you
elect not to?

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.

~~~
timwiseman
Really, your post answers your question. There is value (and risk) in either
specializing or generalizing, and there is room in the world (and the job
market) for both.

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.

------
msluyter
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...

Yoga has been helpful, but I'm wondering how long I'll be able to cope.

~~~
locopati
On the physical demands (speaking as an 37yo coder), I've found these things
to be very helpful...

\- 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

~~~
eru
> \- stepping away from the screens regularly (set a timer to remind you
> because it's easy to blow this one off)

Ubuntu includes an application to enforce breaks by locking your screen. I
have tried it. Works.

~~~
didip
For Mac there's this: <http://tech.inhelsinki.nl/antirsi/>

------
netsp
I think there are some other questions that need to be asked here. I'm not
sure exactly how to phrase this:

"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.

------
lvecsey
What ever happened to the view that some programmers have a capable
productivity that is entire orders of magnitude over others?

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.

------
frossie
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.

The real question is whether the people who "drop out" of the statistics still
wanted to be "programmers" at 40.

~~~
ShabbyDoo
What percentage of mechanical engineers still work as "engineers" a decade
after graduation? The stats for CS majors are meaningless without a baseline
for comparison.

~~~
pmorici
The article gives the number 62% for Civil engineers as a comparison.

------
wglb
Hiring by resume keyword is good only for recruiters, internal and external.

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.

------
mrbgty
Does anyone still think it really matters which programming language a
developer has experience in?

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?

~~~
mattmcknight
Some languages are really different, function, object oriented. While you can
learn to write code in a new language fairly quickly, figuring out what the
best practices are in a new language, what libraries are reliable, can take
much longer. Maybe learning a new language the runs on the CLR/DLR or JVW
isn't quite as different, but languages are ecosystems that take experience in
order to make good decision.

------
akkartik
In other words, if you want to be a programmer all your life, become an
entrepreneur. <http://friendfeed.com/akkartik/5ab60c50>

------
10ren
_The industry turns on a dime, but is slow to retire proven technology._

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.

------
Arun2009
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.

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.

------
eugenejen
I just found the same phenomenon in science career.

<http://news.ycombinator.com/item?id=650898>

~~~
khafra
The similarity raises a question for me--what are the defining characteristics
of a vocation without longevity? What do I do if I like this computer stuff,
and hate doing management stuff, but just turned 30 and can't claim anything
near "guru" status?

------
dave_au
I have a problem with the idea that all the C++ veterans with 10+ years of
experience are priced out of the market.

If they're "too expensive" to hire doesn't that imply that their services are
in demand?

------
c00p3r
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.

