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.
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.
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.
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.
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.
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.
>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.
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...
This 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.
The difference? Every time there's a new switch, they learn it.
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.
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.
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.
Thanks, that is comforting to hear, but I still worry that I'm missing out on some good learning by not knowing many of these people.
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.
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.
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.
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
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.
very true. i think there's a feeling with those guys that the work is inevitably dwindling away, but if they can ride the gravy train until retirement then they'll be just fine. It's a bit of a gamble that the work won't run out, leaving them with a skill that's no longer used.
Who knows in 20 years that may be the case with Ruby devs, getting paid huge amounts of money to keep ancient systems running!
very true. i think there's a feeling with those guys that the work is inevitably dwindling away, but if they can ride the gravy train until retirement then they'll be just fine. It's a bit of a gamble that the work won't run out, leaving them with a skill that's no longer used.
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.)
Don't get me wrong, I think nothing bad of anybody that works in a niche. I just think of it as possible high risk for possible high reward. I might not even include COBOL because it has such a foothold in certain industries. It's just not a new, sexy language. I myself programmed in Pascal back in the day :-)
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!
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.
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.
I think what you're saying really can apply to all ages. Different programmers have different skills they bring to the table. Some have an amazing ability to crank out a utility app that is easy to use. Some are amazing at complex algorithms and scary assembly debugging, but can't and won't ever be able to design a simple form-based app that makes any sense to normal humans. From a programmer stand-point I don't think either one is any better (although the algorithms guy is likely to think his work is more important :-) But depending on the job or position, one of them may be more useful than the other.
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.
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.
The 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.
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.
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.
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...). 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 :-)
I 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.
also 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 )
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.
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.
Isn'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.
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.
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
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.
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.
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.
"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."
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.
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.)
> but as far as the long tail goes, the kids are much less resistant to new ideas
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.
sure, 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.
I 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.
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
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.
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.
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.
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.
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.
"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)."
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.
> 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.
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.
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.
"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.
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.
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.
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.
"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.
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.
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.
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.
I'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).
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.