Old Farts Know How to Code
nick.typepad.com
nick.typepad.com
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.
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.
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.
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.
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.
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.
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...
Those that come to mind were stuck in dead-end programming jobs because they knew only older technologies and supported clients that would not refresh their systems.
One in particular was overworked, underpaid, and cast aside as soon as the one client he supported stopped having enough work to justify a full time position. He was a great guy, smart, great at classic ASP, but he was not receptive to learning new technologies. And he couldn't type. He hunted and pecked at the keyboard. He thought through the code in his head to prevent having to type out code that wouldn't work.
I am scraping my memory, trying to find an example of an older coder that I admire, and I can't find one. I think this is really unfortunate for me, because I know they're out there.
However, there are some network guys I've worked with that knew EVERYTHING. These guys were running dial-up POPs and colocation facilities in the '90s (mid 30's at that time), and now they run all the tech at a local ISP's backbone. These guys were amazing, and I can only imagine I'd continue to be impressed if I kept working with them. The difference? Every time there's a new switch, they learn it. IPv6--they were ready early on. New technology was sought out by them and they craved to understand it all.
For this reason, I think you have to chase at least one or two "fads" once in a while to stay sharp. Otherwise you become complacent, as you are still making a living without doing all that "pointless" work of learning new techniques, frameworks, tools, or languages. But then you may realize that you weren't paddling your boat for those last few hours, and you can't really see land anymore.
This is just an artefact of who you are and where you are in life - and nothing to worry about. How many people outside of your immediate age range do you know anyway? You're almost certainly like most people, who mostly know people kinda like themselves. If you're young you tend to hang with young folk. If you're a good developer you tend to find other good developers. Put both together and it's very easy to think that all good developers are young.
Most of the really good developers I know are in their thirties and forties. That's because those are the people I hang out with coz I'm in my forties myself.
As long as you realise that this is an artefact of who you know - rather than what the world is like - you'll be fine.
I tend to hang out with people 5-7 years older than me (I am 31 now), so I will get there in a few more years, I suppose. I graduated high school early and went to community college for a couple years, then just went straight to work, so that's just the age group I landed with in my professional life.
At the time I made the choice between school and work, one could learn more with computers by just doing work, versus taking a class. All signs indicate that this is still true, unfortunately.
Not my experience at all(1), and I've had one foot in the system administration field and one in the programming field for the last 12 years.
You mention IPv6, but that was an incremental change overall... Pretty much if you knew how to admin a cisco switch back then, you're doing the same stuff now, same for your linux boxen, aside from a few tweaks here & there the basics are all the same.
Maybe 20% changes, tops (compare the first edition of RHCE with the latest), 80% remains the same.
Programming though, every few years something becomes "must have/do"... C++ gives way to Java gives way to PHP gives way to Rails gives way to Node...
(1)This doesn't really apply to the Microsoft stack, which apparently comes out with a new paradigm every few years.
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.
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.
I guess on the internet nobody knows you're an old dog
Especially if you specialize in an obscure bit ERP/MRP software. Yes, it's not exactly cutting edge, but I know folks who do a minimal amount of consulting each month to maintain these systems, which then allows them ample time to pursue more cutting edge work.
Hell yeah. I knew a couple of folk who decided to go into COBOL in a serious way twenty years ago since they saw how the relative numbers of "lines of business critical COBOL" and "number of skilled COBOL developers" were going.
They both made out like bandits.
Who knows in 20 years that may be the case with Ruby devs, getting paid huge amounts of money to keep ancient systems running!
Heh. 20 years ago COBOL was seen in the same legacy "nobody uses it" way it is now :-) I guarantee those two would make the same decision again today - and they'd be right.
The gravy train is only just getting started. COBOL will not go away in my lifetime. People are still writing new COBOL code - and there are fewer skilled COBOL devs out there. There are millions of lines of business critical COBOL running out there in the world.
Usually in businesses that are bright enough to realise that rewriting business critical systems is far more risky than maintaining the existing code (e.g. I was told a few years ago that one particular Large Financial Organisation had taken on an in-house compiler team to reduce the risk of their system becoming unsupportable in the future.)
I was thinking more about some other guys I've ran into. One guy was an expert at this proprietary DB system and slowly would lose clients but somehow always found a new one - charging very high rates. I knew a guy who was quite old when I started and he was an expert with magnetic tape technology! His luck actually did run out, though, his whole department was phased out one day and he had to re-tool (and went into line printers interestingly)
It's really hard to say which of them hang on or not, I have some technologies under my own belt that I feel the same about!
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.
The thing you need to do with the older coder is make sure that their instincts and domain-specific knowledge of something you're hiring for won't mask a deficiency in general programming and problem-solving skills - like the ability to extensively think through all the consequences of their code changes and decisions, or operate in an unfamiliar environment - which will show up later when the rubber actually hits the road.
With the younger coder, the general-purpose programming skills are probably all they have to show you. This is something you need to address in your interview process: just make sure you're interviewing for what you're actually going to need.
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.
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...
Older developers can often rule 80% solutions out immediately - but a younger developer would have to work it out the hard way.
I'm not sure that means anything relative to the whole though. Maybe I was just a bad coder when I was young and now I'm finally catching up.
* 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 :-)
My experience is that there are a lot of "coders" of all ages who can't code.
Sturgeon's Law applies to coders of all ages. That, combined with the facts that coders vary very widely in their productivity, and it's hard to reliably measure a coder's productivity quickly, are the fundamental challenges of hiring coders.
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.
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.
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.
Ah, youth.
You do realize that there's no functional programming language in the top 30 languages on the Tiobe list, and none of the main Microsoft or Apple languages are functional. Most programmers don't know much about the general field of software development, much less follow the fads.
Here's a test: did your father know about Scheme?
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."
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.)
I think that the "old farts" resist "new ideas" mostly because they aren't really new, and they know where those ideas went the last time around. You know, "fool me once, shame on you, fool me twice...";
An example: Object Oriented Databases; when they were popular (early nineties), all the "cool kids" thought the "old farts" were just resisting the "new idea", when in fact the "old farts" had experience with earlier network/entity databases (some of which weren't far from the object databases of the day), and knew why they preferred the relational databases to everything else.
For a modern example: I don't know anyone experienced with HPC who like hadoop. You pay about 10 times (CPU, management costs) for using hadoop compared to actually solving the problem at hand - in return for getting the code to a working state twice as fast (e.g. 6 months without hadoop == 3 months with hadoop). If your problem scale is small, it might seem like a win, but it isn't; If you need 10 servers instead of one, you paid ~$10000 and another month in system administration without noticing. You might still come out ahead, depending on your constraints, but it isn't clear cut.
When you're running 1000 servers instead of the 100 you could have, that's easily a couple of million dollars, which is disastrous for many projects -- and yet, I get labeled "old fart" for not embracing hadoop.
edit: minor edits
I've had exactly the opposite experience. The young guys I come across are resistant to things like FP finally poking into some bits of the mainstream. The old guys are going "Yay! People are finally taking functional programming seriously!".
I'm in my forties. I'm guessing you're in your twenties.
I'm pretty sure both of our experiences are due much more to selection bias in who we know than any age differences in how developers approach problems and "new" technology.
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.
nick: the people who really strike it rich aren't the ones writing code
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.
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.
often excluded from that culture, not because we're lousy
coders
for the promise of striking it rich.
Especially when the people who really strike it rich
aren't the ones writing code.
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
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.
"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.
"Strike it rich" implies fame and impact. You are arguing
terminology.
That is why Peter Thiel talks about CEOs paying themselves a low wage as the best predictor of startup success.
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.
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.
You missed two things: he qualified his statement with often, and he used the word culture. The word culture implies something different than just a command-line and an Internet connection.
I think you miss a point that working hard doesn't equate getting things done. I saw a lot of people working hard (in number of hours) and net gain from their effort is zero or less.You should be focused what kind of results you would expect to have from one day's work or pay me proportionally to my output which can be 10x more than that of hard working guy. I am fine with that. Putting long hours just to fit in culture is not smart thing in the long run. Note one more thing , 'old farts' have more to lose if they do shitty job than some no family/mortgage guy in early 20s.
"Start" vs. "join". I wouldn't want to be a 45-year-old at a typical VC-istan startup where the founders are in their 30s, so "join" isn't much of an option, and I think it's hard to start your own startup if you're older (or more than 10 years younger, except in bubble times when youth becomes hot) than the average VC.
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.
Unless we're talking about a breakout success like Google or Facebook, the CEO and the founders get almost all the fame and glory. A few VPs get decent exit options, and retention packages to balance those. Below the VP level, with a 0.02% slice and with your prospective bosses not liking questions about what preference structure exists against that equity, the startup glory isn't real. Sure, there's open bar at the IPO party, but it's not the same thing. It won't set you up for life.
Also, "making it big" in a startup and not getting a payoff is a bad outcome. I would be fucking pissed if I worked so hard as to bring a startup from scratch to a major exit, only to get robbed by participating preferred and onerous "earnout" shenanigans. Working hard and getting nothing in return isn't virtue; it's waste. The objective function is different in public service or the non-profit sector (where people can work hard without personal enrichment, because they are legitimately serving the world) but startups are just that-- businesses. They exist to make money, and if you don't benefit from one that you started, you've wasted time.
This doesn't mean that startups can't improve the state of the world, but that's not their primary goal or purpose. If you want to improve the world, work for a non-profit or in research. If you work tirelessly to vanquish malaria but never get beyond a middle-class material existence, you've still lived well and done good-- you weren't trying to get rich. If you throw your all into the toughest, most painful, and riskiest private-sector efforts and "make an impact" but never get rich, then you're a chump who got played.
Do you want a guy like this at your company? This is absolutely poisonous from a culture perspective.
Older employees tend to be canaries in the coal mine. They have enough connections and experience that they don't worry about getting fired, and far more importantly, they've been through bullshit before and have seen the worst patterns. The reason older workers don't like to work 18-hour days is that they've done it before (when they were our age) and they've seen that it almost never works. They're more willing to say that the emperor has no clothes.
The problem is that many human organizations (and the majority of dysfunctional ones) bond and judge according to shared suffering, not actual productivity. This creates the culture of working inefficient 18-hour days instead of focusing intensely for half that time and then going home.
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?
That's not what he's actually saying. I am not two-thirds his age, however, and will say that this accurately describes the majority of the current crop of VC darlings and bubble startups (but probably not the majority of all startups). Now is not a good time to join a "hot" startup, unless at a VP level or higher. Real Technology is different (you'll learn a lot) but I'd advise everyone to stay away from "social media" at non-executive levels until the bubble clears.
The reality is that startups are businesses. As with large companies, some are good, some are bad, and most are in-between. Here's the rub: When people join others' businesses, they expect that the people directing their work will take an active interest in their career growth (and, if they're savvy, move on when this doesn't happen). In a startup, this would mean letting the new hire have investor contact and architectural influence, and also (and this one's rarely done) providing some kind of insurance against having people hired above him. Large companies have a lot of problems, and it can be hard to "move up" position-wise, but they actually do better (on average) than bubble startups at investing in peoples' careers, because they're more likely to be around in 10 years.
The problem is that a lot of startups are creating "reality distortion fields" that lead a lot of people to think the rules of "the real world" don't apply. So they take offers at 50% of market salary in companies that don't invest in their career growth in exchange for equity whose median-outcome value is zero.
What's actually overvalued in 2012 isn't startup stock (most of which isn't publicly traded). I think that's fairly valued (meaning that these "obscene" valuations actually reflected the EV of the company's performance, although the implicit promises of growth are bunk). What's overvalued are subordinate positions in startups. A lot of young people are taking them thinking that they're going to get the "startup experience" when, for most of them, they'd do better to join more established companies with better laid-out career paths and, on the whole, more competent management.
Uh, yeah, probably.
Nick Bradbury Ramblings from the creator of HomeSite, TopStyle, FeedDemon and Glassboard Android.
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.
But then I've never been someone who was capable of being productive on 18-hour days. Even at LAN parties, when I was 16, I used to be the first one to go and catch some sleep. Still, having worked in the games industry, I'm no stranger to 12-hour workdays, and communication (face-to-face or otherwise) has never been anywhere near the bottleneck for me there. On the contrary, I used to get the most done in the quiet 1-2 hours before everyone else turned up.
As far as I'm concerned, it's one thing for the founders of a company to put in a lot of hours, but I'd never work for another company expecting employees to do so beyond a reasonable extent (i.e. only when truly urgent).