
Old Farts Know How to Code - breischl
http://nick.typepad.com/blog/2012/05/old-farts-know-how-to-code.html
======
georgemcbay
I'm 38.

I've met older programmers that were exceptional (passionate programmers that
keep up with the craft, eg. at least enough to be able to explain exactly
_why_ they dislike JavaScript but love Go and Python even if they use none of
these languages in their "day job") and older programmers that were mediocre
(these are usually the ones still using only the language they started with,
programming specific types of apps in the niche industry they started in).

I don't think you can pigeonhole this demographic any more than any other, but
there is at least one thing to keep in mind -- the exceptional "old farts" are
_really_ exceptional, because they have the same passion as any other
passionate programmer, plus a boatload of experience. When you really want to
ship something, no amount of youth-fueled semi-experienced 16 hour workdays
makes up for a solid 8 hours from someone with decades of experience who still
loves writing software.

~~~
adrianhoward
_older programmers that were mediocre (these are usually the ones still using
only the language they started with, programming specific types of apps in the
niche industry they started in)._

This is one of the reasons some folk think older developers get worse. The
mediocre young developers very naturally end up using the "cool" languages -
because they're the ones that are popular and fashionable at the time they
move into development. Their rigidity only becomes obvious as the years go
past and the world moves on without them.

(Not that there aren't good and valid reasons for sticking with "old"
technology that just works. I have to admit I'm kind of looking forward to the
point in five or six years time when the Rails folk have to start justifying
why they're not using the NewCoolThing :-)

 _I don't think you can pigeonhole this demographic any more than any other,
but there is at least one thing to keep in mind -- the exceptional "old farts"
are really exceptional, because they have the same passion as any other
passionate programmer, plus a boatload of experience_

I think it's even better than that. Experience can help turn a mediocre
developer into an excellent one. I find the idea that some people have that
experience makes people perform worse somewhat bizarre.

------
api
I have met lots of _highly_ skilled older coders. They tend to not jump on
every fad, but that's because they know that software engineering is faddish.
Instead they focus on deep expertise, robust architecture, and how to ship.

~~~
maybird
The problem is that older folks are very few and far between.

You're right about shipping I think. My experience is only anecdotal, but
older people, for me, have been the difference between shipping and
floundering.

~~~
tjic
I was thinking the other day "if I wanted to market myself as a 40 year old
RoR contractor, what's my one paragraph description / resume / pitch".

It boiled down to:

After 20 years of experience at startups, my key skill is simple : I GOD DAMN
SHIP WORKING CODE. I'm up on some of the latest technologies, and not up on
others, but if you want someone to take a half-assed project that's over
schedule and over budget, get it cleaned up, made working, made maintainable,
debugged, and DEPLOYED - with every little quirky bit that separates 'mostly
done' from 'actually done', then I'm your man.

~~~
tjic
A further thought: PG talks about Blub languages and Blub programmers (in both
cases, those at level X can look down at level X-3 and see what it's missing,
but those at level X-3 look up at level X and just thing "WT*?").

I think that there's an aspect to software engineering that is not captured
under the word "programmer", and there are Blub people in this as well: people
who know how to get projects finished, maintainable, and deployed understand
how the Blub folks fail, but the Blub folks don't understand everything the
old farts do, and think that most of it just looks stupid or stick-in-the-mud-
ish.

~~~
batista
> _A further thought: PG talks about Blub languages and Blub programmers (in
> both cases, those at level X can look down at level X-3 and see what it's
> missing, but those at level X-3 look up at level X and just thing "WT_?").*

Which I find mostly a Blub observation. Yes, some languages have some more
features than others. In any case the benefits are marginal compared to: their
libraries, the general ecosystem (programmers, jobs, books, etc), stable,
fitness for the job etc.

It's not like anybody will be more proficient writing a kernel or a 3D FPS in
Lisp, just because it has garbage collection and C lacks it. Actually, C will
be better suited for the kernel job PRECISELY because it lacks garbage
collection.

And if you are in rural Romania, you'd be better of with CodeIgniter for your
brochure-style web design firm, than with Snap, that is if you want to have a
team with more than one programmer in it.

------
zdw
Most of the older coders I know tend to focus on niche technologies. Many do
embedded systems work, or database design.

The downside is that some of them really fell in love with a certain fad - for
example, one of the great database designers only builds Access/MSSQL stuff
because he knows it inside and out, backwards and forwards. I know similar
people who are stuck in Crystal Reports, Delphi, etc.

I get the feeling that older coders tend to dismiss all the current fads, and
are stuck in the fads of 10+ years ago. If I needed help with one of those
technologies, I'd be certain to call one of them, but it does cut them out of
consideration for new projects...

~~~
huggyface
_Most of the older coders I know tend to focus on niche technologies. Many do
embedded systems work, or database design._

Specializing is often very lucrative. Ruby on Rails and PHP programmers are a
dime a dozen (no literally they are astonishingly cheap), while a database
designer is mid six figures. It is hard to get into those specialties, so
naturally they are going to have older participants.

 _I get the feeling that older coders tend to dismiss all the current fads,
and are stuck in the fads of 10+ years ago_

That is a short circuit argument often used by people when they face
resistance to unsupported ideas. Several years back I posted several essays
critical of the NoSQL euphoria. Being in my 30s, I wasn't surprised to see
several argue that it was because I was just too old, man. Only that was a
steaming pile of horseshit: My criticism was founded entirely in a
knowledgeable, experienced analysis, and not simply brash adoption because
something was new and different (an affliction that impacts developers of all
ages). The new silver bullet.

People see what they want to see, and it's the root of all prejudices.

~~~
bunderbunder
_Several years back I posted several essays critical of the NoSQL euphoria.
Being in my 30s, I wasn't surprised to see several argue that it was because I
was just too old, man. Only that was a steaming pile of horseshit: My
criticism was founded entirely in a knowledgeable, experienced analysis, and
not simply brash adoption because something was new and different (an
affliction that impacts developers of all ages). The new silver bullet._

Reminds me of an experience I recently had. I was in a room full of
programmers where the conversation quickly turned into an exchange about newer
technologies between a group of mostly up-and-coming Ruby guys (who I'll call
'youngsters' for lack of a better weasel word), and a group of mostly older
and established enterprise developers (the 'oldsters').

It was weird to sit on the sidelines and watch the exchange. The oldsters were
asking interesting and probing questions about some of the technologies that
were popular with the youngsters. Nothing really confrontational. Just a lot
of genuine curiosity, tempered with a little bit of cautious skepticism
(presumably borne of experience).

The youngsters, on the other hand, seemed to be taking all of it rather
defensively. And they did a whole lot of question-dodging. Or apparently
failing to understand that they failed to understand the question (admittedly
I didn't really understand a lot of these questions either - I'm a youngster
myself), and giving unsatisfying answers as a result. And generally making me
worry that the Dunning-Kruger effect might have been a factor in how the
conversation was unfolding.

Don't know where I'm going with this, other than to say that it was a rather
instructive experience for me.

~~~
adrianhoward
I've had one entertaining experience at a conference of having my opinion be
partially dismissed in-person due to my age - only to have a guy bring up what
this "Adrian Howard" dude said on a mailing list to back up my old-dude
opinion (I hadn't introduced myself at this point).

I guess on the internet nobody knows you're an old dog

------
jakejake
I can relate to this article, but I have to say that not all older people know
how to code. I'm pretty much at the age mentioned in this article so my peers
are all "old farts" in the tech industry. Some of them evolve into excellent
programmers with valuable experience. Others are very change resistant and
possibly never had good practices in their career. Some have had cushy jobs at
corporations and move at the speed of a snail. Others crank out solid code at
inhuman speed.

Basically I think older coders need to be evaluated the same as younger guys.
Some are good, some are not. However I do agree that older guys with families
are not going to work 24/7 for 6 months in exchange for free pizza.

~~~
eshvk
The problem lies in how a start up should evaluate an "older person". I am
fresh out of school and think it is completely natural to be asked about new
technologies, dynamic programming etc. However, I know a guy in his late
thirties who has this inhuman ability to learn a fancy new technology in a
week's time and then apply it to solve a complex old problem. Unfortunately,
he doesn't necessarily have as good an algorithms background as I do. However,
the speed at which he gets stuff is amazing. Does that mean that he is not a
valuable asset? Also, how do you distinguish between such a person and a
person who has spent a decade in industry and can run circles around you on
high level stuff but is lacking when you dig deeper? When I am interviewed for
a position, I expect (and even appreciate) being given a coding challenge and
being asked to present my github account but I am unsure how scalable that
model is for a senior person who has family etc.

~~~
cunac
it is given that minimum you should be able to do is to code but that doesn't
say at all can you actually develop something (think about that for moment)
Low level stuff is generally easier to master (hence low part in name) than
high level abstract thinking and concepts. Most people can learn low level
stuff but most people doesn't grok high level stuff and implications of
decisions they make.

~~~
eshvk
Yeah but I would think that evaluating whether a person can code or not is
hard. (From both personal experiences as an interviewee/interviewer and the
large number of posts regarding interviews that we see on HN every day).
During my limited "oldster" interviewing experience as part of my startup job,
I have found that people who have spent a long time out of academia find it
(slightly) harder to solve questions on trees, graphs etc. On the other hand,
they do cream the shit out of problems that you face in your day to day job in
industry. On the other hand, people who are fresh out of school typically have
the situation in reverse. I myself again feel the best way to evaluate a
person's coding ability is to ask them to work on a tiny project. However, it
doesn't seem reasonable to ask a person coming in for a senior position to
work on a silly coding challenge.

------
leed25d
It warms my heart to read this blog post. I have been programming pretty much
continuously since 1974 except for a brief two year foray into management. I
intend to keep on programming for as long as I can.

I would like to make a brief remark about passion. Leaving aside the fact that
the term 'passion' is sometimes overused, I think that a lot of --especially
younger-- people confuse passion with a kind of frantic, frenzied intensity.
That kind of passion typically does not last very long, I think. It either
burns itself out or it mellows into a deeper, more mature, kind of devotion to
one's craft.

------
jgrahamc
Whilst I agree with the title of this post, it would be nice to have some
evidence, or at least some examples of the sort of things that experience
brings.

Related: "The Secret Life of the Grown Up Brain" is an interesting book
looking at what works and does not work in the middle-aged brain (defined as
being 40s, 50s, 60s): [http://www.amazon.com/The-Secret-Life-Grown-up-
Brain/dp/0670...](http://www.amazon.com/The-Secret-Life-Grown-up-
Brain/dp/0670020710)

~~~
mtkd
Long experience in development is often more about knowing what won't work as
much as what will.

Older developers can often rule 80% solutions out immediately - but a younger
developer would have to work it out the hard way.

~~~
adrianhoward
I listened to rather a nice talk by George Fairbanks at GOTO Copenhagen kinda
related to this topic on Tuesday
([http://gotocon.com/cph-2012/presentation/Master-
builders%20h...](http://gotocon.com/cph-2012/presentation/Master-
builders%20have%20rich%20conceptual%20models%20of%20software%20design)). One
of the things he brought up was the idea of what you'd tell your twenty year
old self to get them to be as skilled as you are now - and it was a hard thing
for me to answer off the cuff. After a couple of hours I was thinking about
things like that I pretty much totally misunderstood in my twenties.

* Building software is much more about people (both the team and the users) than it is technology. So called "soft skills" are vital to shipping.

* Value starting small and growing a system, more than starting large and solving everything.

* Validate what you produce. Do it with the shortest feedback loops possible.

* Build up abstractions from working code, don't create working code from abstractions.

* Make sure that you build the abstractions from the problem domain/solution into the code, not just the abstractions you need to make the code easier to produce and comprehend

* Always be able to explain the decisions that you make in development.

... and of course the shit load of experience that doing development for
thirty years in multiple domains, teams, languages, contexts, etc :-)

------
dkhenry
I have recently been in the position to hire some older coders and, This
article needs this grain of salt. There are a lot of older coders who can't
code which masks some of the real great programmers out there. The other
problem is once someone gets established as a cornerstone of an organisation
they aren't normally let go. There is too much intellectual knowledge ties up
in the individual. So what you see on the market is older programmers who
couldn't cut it at their employer and then eventually got let go . That's why
you see so many people passing on them.

~~~
trimbo
> There are a lot of older coders who can't code

My experience is that there are a lot of "coders" _of all ages_ who can't
code.

------
endlessvoid94
I'm almost finished with "The Art of Unix Programming" by Eric Raymond, and I
have to say, I wish I would've read it years ago.

We constantly, I mean _constantly_ reinvent things. Not just tools, but
techniques and patterns. I'd love to talk to some older developers about this
-- or read a good blog.

~~~
jff
You want to make your way in the CS field? Simple. Calculate rough time of
amnesia (hell, 10 years is plenty, probably 10 months is plenty), go to the
dusty archives, dig out something fun, and go for it. It's worked for many
people, and it can work for you. - Ron Minnich

------
etrain
The software industry allows for something that's pretty unique - two people
can have the same title/role, but one of them might be 100x more productive
than another. While some of this difference can come down to innate ability,
much of it is about experience and the judgment that comes along with it
(better design decisions, architectural sense, etc.)

To that end, it's really bizarre to me that the industry doesn't value its
seasoned employees more. These guys have as strong an ability to be a 100x
programmer as anyone else.

~~~
ascendant
As he points out, the industry likes young kids that can be paid less and
worked harder. People that are old enough to know better are generally viewed
as "cancerous" because they tell the younger people they don't have to throw
away their youth to make other people rich. The people trying to get rich
generally don't like that.

------
dustingetz
in the poker world, there was a turning point around 2002, where all of a
sudden out of nowhere, 22-year-old kids were DESTROYING the "old fart"
professionals - the kids learned poker on the internet, and condensed a
lifetime of learning into two years with better learning materials and faster
play.

this may or may not be happening now in the programming world.

i've met a handful of "old fart" programmers who are exceptional. i've also
met a handful of twenty-something programmers who are equally exceptional. but
as far as the long tail goes, the kids are much less resistant to new ideas,
new concepts (for example functional programming). i think it might be a
generational difference, and i think it could shake up the software economy in
the next decade.

edit for the trolls: new to a particular person, not to the world. functional
programming is a new concept to most of the people i've met, including several
very strong engineers.

~~~
dalke
"new concepts (for example functional programming)"

New? Functional programming has been around since the 1960s. ML was first
available in 1973. Haskell was first released in 1990. Even Python, a
decidedly non-functional language, included the "map", "apply", and "reduce"
builtins in its 1.0 release in 1991.

The author of the essay says that 45 is often considered "old fart" age.

Let's say someone was 25 when Backus presented "Can Programming Be Liberated
From the von Neumann Style? A Functional Style and its Algebra of Programs" in
1977. That's 35 years ago, making them 60. Or perhaps the reference date
should be when "Structure and Interpretation of Computer Programs" came out in
1985? Making them 52 now.

(I picked age 25 since at age 20 they would be "out of nowhere, 22-year-old
kids" you were talking about.)

By neither criteria is functional programming new enough that a 45 year should
consider it a "new concept."

~~~
adrianN
If you take the existence of papers as a measure about what is relevant for an
industry programmer, then I hope you are familiar with things like writing
formal proofs using Coq and Isabelle (Coq started in the eighties), or
generating programs directly from a specification.

~~~
dalke
I don't. That's why I included SICP in 1985 as another reference point.

Quoting from Wikipedia on "Functional Programming": Also in the 1970s, the
development of Scheme (a partly functional dialect of Lisp), as described in
the influential Lambda Papers and the 1985 textbook Structure and
Interpretation of Computer Programs, brought awareness of the power of
functional programming to the wider programming-languages community.

Even then, my own knowledge of functional programming started in the
mid-1990s, as a physics grad student. It wasn't good knowledge, most
assuredly, but enough that I am confident that a hot-shot young developer of
1990 would know the basics about as well as a hot-shot young developer now.
Oh, and I even remember my advisor coming in one day exclaiming that we should
all learn Dylan; that it was the new, elegant language of the future.

("About as well" because there 1) there's more documented experience with
functional programming, and 2) there are many more developers now, so
statistical distributions say that there are going to be a few more people now
who know it better than they did then.)

------
oldfartbs
I'm 41 and the old fart argument is bullshit.

People are people and they are all different. I don't cling to old technology.
I love learning new things. I have written C modules for every major scripting
language, modules for every major web server, can automate GDB and Windbg
alike and have seen so many problems, I often can solve them with a walk buy
and a mic drop. I am more productive now than ever, and I started coding when
I was 10. Was sysop of a chat BBS when the Challenger blew up. Ran slackware
in the early nineties, stood in line for Windows 95. This isn't just an alpha
geek rant -- the point is that if you really love what you do, you only get
better. My workflow is so automated from years of the craft, people that see
it are in utter disbelief. I have so much quality code in the kitty that I can
produce faster than anyone I have ever worked with. The bottom line is that if
you produce results, you are of value. I prefer to code in C and ruby, but
have no problem switching to .Net, Java, python, node, or whatever. The right
tool for the job, and I can make that call better than most because I've
learned it's not always about technology, it's about the passion the team has
to get the job done. As the levels of abstraction in modern technologies get
further and further removed, the more you want people like me on the team.
Your business might just depend on it.

------
j_baker
One thing worth pointing out: not all startups are created equally. You _will_
run into the stereotypical startup that will drain you dry so the founders can
make millions off of a talent acquisition. But there _are_ plenty of decent
startups out there that aren't run this way.

------
earl

       nick: the people who really strike it rich aren't the ones writing code
    

this this this. Except for a few companies that come around a handful of times
in a generation (Google, fb, et al) coders don't get rich at startups.

~~~
michaelochurch
Well-said. _Founding_ a startup can be lucrative. Joining someone else's?
Unless you're VP level or above, it's generally not a good move financially
speaking. (If you're a non-founding first programmer, demand a VP-level title,
investor contact, and the right to attend board meetings-- voting rights are
probably not an option. Titles mean nothing early on, but you want to lock
that in to make it clear that you're not a JAP, where JAP means "Just A
Programmer".)

For every other case, the rules for joining a startup are the same as for any
other company. Join if it's a promotion, and if the gains outweigh the risks.
A lateral move (salary wise) into a startup is fine, but if there isn't some
level of technical promotion, at the least, it's not worth doing. Also, the
mere fact of it being a startup does not a technical promotion make; a lot of
these bubble startups are using the worst kind of enterprise Java.

As I said in another post, what's actually overvalued in 2012 is not startup
stock, which probably reflects an accurate EV for these new ventures, but
subordinate positions within startups.

------
michaelochurch
_The startup culture is similar to professional sports in that it requires a
fleet of fresh-out-of-college kids to trade their lives and their health for
the potential of short-term glory._

This seems to be true in these "social media" VC-istan bubble startups, but is
it true in Real Technology? (This assumes VCs are still funding Real
Technology.)

I know some people in their 40s who started a biotech firm and seem to have
balanced lives, but this was also in another country.

------
temphn
There are several points this guy doesn't acknowledge:

    
    
      often excluded from that culture, not because we're lousy 
      coders
    

If he is an amazing engineer, he's not "excluded" from the culture. You need a
command line and an internet connection to start your own thing.

    
    
      for the promise of striking it rich. 
    

Few people do startups for the "promise of striking it rich". They do it to
"make it big", which is not the same thing. They are more fame- and impact-
motivated than dollar motivated. So this right there bespeaks the wrong
motivation.

    
    
      Especially when the people who really strike it rich 
      aren't the ones writing code.
    

If he's not starting his own thing, he expects someone else to pay him a
salary. But then turns around and says that coding is the _only_ source of
value. Guess what, it's _harder_ to raise money for a technology startup than
to get up a Rails site. Many more people can do the latter than the former,
and it's not for lack of wanting. So from day minus one (not even day zero of
signing or day one of working) this guy is _already_ hating on the people who
hired him and pay his salary (often in addition to coding the first
prototype), without even understanding what they do. Why would you hire
someone like that?

    
    
      trade their lives and their health for the potential...we 
      won't put up with that shit. We have lives, we have 
      families, we have other things that are important to us. 
      We're not about to sleep at our desks and trade watching 
      our kids grow up
    

Do you want a guy like this at your company? This is absolutely poisonous from
a culture perspective. Not only does the guy not want to work hard, he equates
working hard with "losing your health". Somehow I missed seeing that Levchin,
Thiel, Brin, Zuckerberg, Pyncus, and every early Googler and Facebooker were
in wheelchairs for carpal tunnel syndrome. It's really not that hard to work
hard and work out at the same time (even the dreaded brogrammers manage it).

If you are an engineer, you have to admit that tradeoffs exist. Go home and be
a family man, like Guile's famous taunt, just don't expect to _also_ become a
multimillionaire at a hot tech startup in an intensely competitive environment
without any sacrifice of time. After all, you've got your wife and kids, and
startups are all stupid scams meant to bilk the coders, so why feel excluded
from anything?

Answer: because he doesn't believe his own analysis. He wants someone else to
prop him up, to raise money and employ him, to provide the structure and the
idea for him, and to organize everything into nice clean chunks that he can
knock out with no technical risk in 40 hours per week, resenting them the
whole way.

Guess what: the kind of person who can do that doesn't want to work with
people like this.

~~~
huggyface
_So this right there bespeaks the wrong motivation._

"Strike it rich" implies fame and impact. You are arguing terminology.

 _Do you want a guy like this at your company? This is absolutely poisonous
from a culture perspective._

Absolutely. I will _always_ choose people who work smart over people who work
" _hard_ ". Always. As to being poisonous, if someone refusing to give up the
life balance is "poison", it's because you already are on life support.

Astonishing how much narrative you've invented in your reply.

~~~
temphn

      "Strike it rich" implies fame and impact. You are arguing 
      terminology.
    

They are not the same. Wikipedia, Khan Academy, Linux and Rails are fame and
impact. Github is smaller than Zynga but has much higher status in the
programming community. You can't go long years with low salary if you are
motivated by money. This isn't just double think, the kind of people who
achieve high economic status via startups usually care more about social
status and proving something to themselves and the world than fancy cars.

That is why Peter Thiel talks about CEOs paying themselves a low wage as the
best predictor of startup success.

~~~
huggyface
_Wikipedia, Khan Academy, Linux and Rails are fame and impact._

Jimmy Wales is worth some $25 million, and basically lives his life off the
Wikipedia books. Linus can write his own ticket anywhere, and has virtually
unlimited potential. Rails....partner at 37 Signals.

If you have fame and impact you can almost always convert that into a lot of
cold, hard cash.

~~~
temphn
Right, but it's about the psychological state. Jimmy Wales made his money
outside of Wikipedia. Linus wasn't doing Linux to get rich. If you read their
bios, the Google guys weren't thinking about getting rich. Of all the recent
crop of successful startups, maybe only Mark Pyncus was really focused on
getting rich.

It's a bit zen but there is a good way to tell the difference. A successful
startup founder, when presented with the choice between more money and more
power, will take power every time.

------
joe_the_user
I think the question isn't whether someone can code but whether someone is
willing to work eighteen hours days.

Even if someone could turn out more good code in eight hours than the rest of
the team turns out working eighteen hours, well not being around makes it
harder to be part of the team.

But I'd say this is more of a testament to companies and standard practices
which are more oriented to working people to burn out and throwing them away.
That's not an efficient use of people certainly and it may not be an efficient
use of the people's time. But it might just be an efficient use of the
investors' money.

In ways, I'd say perhaps the young-guns might see that hiring old-farts could
be a way to put a break umpteen-hour-weeks and so prevent the operation from
having a burn-out-and-throw-away quality.

~~~
EliRivers
I've been a programmer for more than a decade and 18 hour days are few and far
between. This bizarre obsession with long hours seems to be common in a very
small segment of the programming industry.

~~~
eshvk
Oddly enough, I see quite a few startups where this is prevalent and even
celebrated. I remember talking to a YC company where top-down from the CEO, I
was told that everyone worked 80+ hours a week and people were proud of the
fact that occasionally they slept under their table. Looking closer at the
operation (I spent a good few hours at their work place), It seemed apparent
that most people were around late in the nights not because they were doing
focused work for 18 hours but because they were inefficient enough that a
significant bit of time was being spent doing other meta-non work related
stuff. I suspect one of the reasons for this was that their "open office"
environment was so incredibly distracting that there was so much context
switching going on.

