13 ms·
Old Farts Know How to Code
- jgrahamc 14y agoWhilst 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/0670020710 http://www.amazon.com/The-Secret-Life-Grown-up-Brain/dp/0670...
- mtkd 14y agoLong 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.
- rapind 14y agoI for one definitely solve problems significantly faster and cleaner than I used to when I was starting out. Nothing sticks like learning patterns 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.
- cunac 14y agoalso older people should be more aware of what and how much they don't know. Keep in mind that any decent 'old fart' did ship to production and support at least handful of applications with actual users (hint: time before internet )
- adrianhoward 14y agoI 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%20have%20rich%20conceptual%20models%20of%20software%20design http://gotocon.com/cph-2012/presentation/Master-builders%20h...). 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 :-)
- api 14y agoI 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 14y agoThe 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 14y agoI 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 14y agoA 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 14y ago>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.
- jakejake 14y agoI 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.
- fennecfoxen 14y agoThe problem with hiring an older coder is the same as the problem as hiring a younger coder: they might not actually be very good. 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.
- eshvk 14y agoThe 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.
- georgemcbay 14y agoI'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.
- dnc 14y ago"It is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead."-- Edsger W. Dijkstra
- adrianhoward 14y agoolder 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.
- etrain 14y agoThe 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 14y agoAs 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.
- dkhenry 14y agoI 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 14y ago> 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.
- huggyface 14y agoIsn't what you described true of the entire job candidate market? Naturally the ones applying will be dominated by the unemployed, the let go, and the ones that haven't been picked up. This is true at all ages.
- jleader 14y ago"There are a lot of older coders 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.
- joe_the_user 14y agoI 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 14y agoI'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 14y agoOddly 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.
- pmjordan 14y agoI'm not really sure what point you're trying to make here. I completely fail see the logic behind 40-hour days making it hard to be a team player. I have to say most of the time as a programmer I'm staring at a screen on my own, even when I worked on a projects with 50 people. 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).
- earl 14y agonick: 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 14y agoWell-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.
- zdw 14y agoMost 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...
- MiguelHudnandez 14y agoThis matches my experience, as well. I have not had the privilege of knowing many older coders, at least none that I admire. 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.
- dustingetz 14y agoin 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.
- mattvanhorn 14y agoSince when is functional programming a "new concept"? Ah, youth.
- rumcajz 14y agoOld farts may remember that functional programming is used since 1950's.
- jes5199 14y agosure, but my father was a professional programmer from the late 1960s until the 1990s, and he had never heard the term until I told him about it, in like 2005 - when it became a fad.
- dalke 14y agoI suspect that most professional programmers haven't heard of functional programming even now. 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?
- j_baker 14y agoOne 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.
- leed25d 14y agoIt 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.
- temphn 14y agoThere 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.
- 14y ago
- endlessvoid94 14y agoI'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 14y agoYou 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
- michaelochurch 14y agoThe 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.
- oldfartbs 14y agoI'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.