Silicon Valley's Dark Secret: It's all about Age
techcrunch.com
techcrunch.com
You'll start to see the downsides as you approach 40 though. Many programmers can't play the social games that management requires, there's a limited number of "architecture" slots, and you're suddenly competing neck & neck with people twenty years younger willing to work 60+ hours a week for half your salary. It's brutal but you've just got to knuckle down and do your best to keep up. Leverage your experience to learn new tech faster and constantly work on moving yourself upmarket technically. You've been in a footrace all this time but you may not have noticed it until now.
That sounds nice on paper, but there are a lot of extremely talented and productive young programmers on the market now. The kind of education you can provide yourself if you really dive into the open-source world and things like github simply wasn't available even ten years ago. So yeah, do your best, in the old fashioned sense of the word before people became so enchanted with non-sequiturs like 110% performance.
Really? There are certainly a lot of young programmers who think they are extremely talented and productive, but 'twas ever thus. I'm still waiting to meet the 20-year-old who is as smart as I'm sure I was when I was 20. :-)
> The kind of education you can provide yourself if you really dive into the open-source world and things like github simply wasn't available even ten years ago.
And why would you assume that people who have access to that and ten years' extra experience would be somehow inferior to those who have access to that without the extra experience? The availability of open source code to explore is a potentially useful resource, but it's only one resource. Reading is still no substitute for doing, and it's not like many of the older programmers today never worked on hobby projects before the Internet came along.
I don't. I just don't assume I'm superior either.
If not, re-read Patrick's comment with that in mind.
I seem to have been bitten by the radioactive spider that allows me to reliably post the highest-ranking "who's hiring" comment here, and your perspective on the availability of domain expert programmers doesn't square with my reality.
Of course, the smartest thing you can do as a senior programmer is build domain expertise and get out of the more commodified areas, like web app dev. If that's what you & Patrick are suggesting I agree, but you underestimate your juniors at your peril.
If your friends are making $100k/yr, they are squarely in the same hiring demo that 40 year old senior devs are.
The whole thesis behind the article you are commenting on is that companies are hiring young because young devs are cheap. You made a comment to the effect of, "watch out, young cheap people can be domain experts too". I think you're mostly wrong, but I'd love it if you were right, and I'm very much putting my money where my mouth is.
I know that there are anomalously capable 25 year olds out there. I'd love to talk to them, too. But the idea that all of Silicon Valley is built around those people rings false. It may very well be built around 25 year olds, but not the weird ones that run High Frequency Trading Engine teams.
I'm not denying that older, experienced programmers with strong domain skills are in demand, of course. I'm just saying that beneath that level the competition is heating up.
Re-read Patrick's comment, but this time, take the Cliff's Notes with you:
* It's not enough to be better; you have to find ways to be measurably better; implied: better along axes that people who write checks care about.
* Learn to market yourself; implied; the business world is not like Github, and nobody is going to invest any effort into learning how awesome you are, because your awesomeness is not inherently interesting to most people who write checks. You have to make it interesting.
* Develop non-commodity domain expertise; implied: not only is "learning Merb" not a credible differentiator, but, all respect to Yehuda Katz who is smarter than me, it's likely that writing Merb isn't either.
* Own your company.
The fact that Patrick managed to pack this into 91 words and all you appear to have taken from it was "Do it ridiculously better" may account for some of the downvotes.
Patrick's built a nice business for himself but I spent the last ten years working with some of the people that wrote the foundational research papers on computer graphics, not building bingo card generators, so maybe we're looking at this from different ends of the pipe.
Cageface: the old guys better watch out because there's lots of hungry smart young guys.
Patio11: anyone regardless of age needs to understand how they create value and aggressively point this out unambiguously. And creating value doesn't mean solely working hard or being smart.
Cageface is cautioning to not assume more experience means higher value. Patio11 sorta did the same thing cageface did earlier and keyed in on the "60+ hours" bit. His (patio11) point is that the way to demonstrate value is not to count yourself among the young, or old, or authors of foundational research papers on computer graphics.
I've been in my position a few years now, and I have accumulated domain knowledge that is valuable to my employer. I have no doubts that someone else could come by this body of knowledge, but it would certainly take time an mistakes. If I do not make these differences obvious (measurable and visible), I fail to do so at my own peril.
I'm turning 21 in a couple months, for whatever it's worth.
The same explosion of knowledge that open-source and github has spawned has created a wealth of new niches that are quite promising but generally underexploited. Everybody's piling into Ruby on Rails, Django, JavaScript, iPhone, and Android development. How many people are piling into things like computer vision, large-scale data mining, wearable computing, or robotics?
Search was not sexy in 1998. E-commerce was sexy. Everybody piled into E-commerce, which left the field wide open for Google to come in and clean up while Pets.com withered away and died.
My probably naive question is, how come you earn twice as much in the first place? Shouldn't salaries reflect the value you provide to your employer, so that either 1) you don't earn as much because you're actually worth less than the 60+ hours working kid, or 2) you earn twice as much because the hours you do put in are worth more than the kid's hours?
I would hate to be out of a job at fifty because by some arbitrary convention I'm supposed to either earn twice what the kid earns, or alternatively be jobless. If I can't provide more value than the kid, then pay me as much as you'd pay him.
But in reality, salary worth is determine by your negotiation skill within that limited time window before you accept the new job. And that's another industry's dirty little secret.
My guess is that all other things being equal, a bad negotiator won't actually catch up to a good negotiator. If things are not equal though, and the good negotiator sucks at his job while the bad negotiator is absolutely rocking it, I think that the strong technical person could easily make up the difference through promotions and bonuses.
At least I'm not chained to an S.F. mortgage that means I can't live on < $90k/year.
Do you want to be the person that loses the company some amount $x, comparable to your yearly salary, when you make a mistake? Or are you willing to lose the company 100($x) for making the wrong decision, be fired for it, and have your entire team looking for jobs?
I tend to think of it as "how much of the buck are you expected to stop?"
(http://en.wikipedia.org/wiki/Buck_passing for non-US HNers)
If it were the case that "salaries reflect the value you provide to your employe" we'd see some people making 10, 25, 50 times as much as "average" or below programmers. And I'm sure you can figure out a bunch of reasons why that would never fly in addition to the other replies to your query.
I agree with your sentiment, but I think you're missing something important: it is possible (and, unfortunately, quite realistic) for a low-level programmer to be "negatively productive". For difficult problems, it may simply not be possible for someone without the required skill and experience to find a solution. Even for easy problems, though, it's possible that the solution found by a weak developer will in the long run cost more than the benefits it offers, for example, because they reduced the overall design quality of the system and later a stronger developer has to spend their valuable time fixing the design to clear the technical debt.
However, it's not as simple as that: you absolutely must have a broader set of skills to work effectively in these ways. There are many management and communication skills that you wouldn't need much working in a technical role as an employee that are quite simply essential to working independently, and more still if it's not just your own work to be organised but a whole team/company. Also, you are operating without the safety net that being an employee provides: you typically bear all of the risk if you're on a high-margin fixed-price contract that overruns by a year, or if you put your own money into starting a company and your idea just doesn't work out.
Ha, I hadn't thought about this aspect at all, thanks. But would you necessarily need to assume the pay should be directly proportional to performance? Perhaps earning double as much when you're 10x more effective is more reasonable, and then triple at 100x - say, a logarithmic scale? Also, productivity and hours spent are both only partially reflecting the total value someone brings.
Well, in any case, I was thinking about _some_ kind of system where your value would be expressed and not some irrelevant metric like age.
For reasonable definitions, I think compensation would have to be directly proportional to effectiveness, such that being twice as effective results in twice the compensation.
That would be the case if "effectiveness" meant "your responsibility for the firm's revenue." Otherwise, what are you measuring, such that you can be "10, 25, 50 times" as effective? Efficiency of coffee making?
Maybe they do.
An hour of one person is not always worth the same money as the hour of another.
Experience is a differentiating factor, and older people tend to have more of it.
That doesn't mean that every older person is worth more than every younger person or that every older person is more experienced than every younger person.
But if I can decide between hiring two guys, one that is experienced and gets the job done by working 40 hours and has a life and the other that works 60 hours and has no life I'd go for the one that works 40, whatever the age.
So if you're afraid to be out of a job at 50 because you're going to be 'expensive' work smarter, not harder. Provide the same value without having to put in the same number of hours.
That's the best way to guard against obsolescence.
In reality, you pay an employee just enough to keep them happy. As long as they're below the threshold where they're worth the cost, that is. Better employees have a higher threshold, but not necessarily a higher salary. It all depends on what they need and demand - which only has a marginal correlation with actual value.
Speaking from experience - there have been a few times we've given raises to great employees who were already happy with the salary they were getting. It didn't have much of an effect, really - we would have been better off investing that money in a better work environment - which would have a much more positive effect on our employee happiness.
I mean even with new technologies, if you end up building sophisticated CRUD interfaces with language FooBar 20 years from now, you can't really complain about it.
People who managed to differentiate themselves in CS over the years moved to stuff like computer vision, natural language processing, designing programming languages, optimizing virtual machines, designing protocols or mixing their knowledge of CS with another field.
Very advanced stuff which takes years (if not decades) to master and to write/build properly.
So, I would only worry if 20 years from now, you're still solving the same problems but with a cuter UI and a faster machine.
PS: Should have used "one" instead of "you". I don't mean "you" ;-)
Exactly. You have to constantly reinvest in yourself technically. Learn new languages and platforms, study a new business domain, hack on at least one side project and keep it up on github. There is no such thing as tenure in software.
As long as management insist on perceiving themselves as superior to other people, and assuming that technical competence somehow implies management competence, there will always be a drain on the good technical guys. The reward and recognition structure strongly encourages them to change discipline. However, can anyone cite me a single source that justifies this position? I'm not sure that any company I've worked for, of any size, really got more value from its middle managers than from the senior technical people it keeps trying to turn into middle managers.
The assumption that architecture/design is more important than front-line coding is also dubious. A good architect/designer is worth their weight in gold on a large project (just like a good manager), and to be sure you probably need a fair bit of experience to be any good at all in that sort of role. But that just means the low end of the scale for that role is higher, it doesn't mean the high end of the scale for front-line coding jobs has to be lower. All the evidence I've ever seen still says an expensive, high-end front-line coder is disproportionately productive compared to a cheap, lower-end worker. You can have the best project management and the best design in the world, but if all the guys implementing it are chumps, your project is still going to suck.
Management error #2: "Even though you may be highly experienced and wise, employers aren’t willing or able to pay an experienced worker twice or thrice what an entry-level worker earns."
That's because they're dumb... Maybe because they got too many technical people to do their management instead of people who are actually knowledgeable about and good at management? Project costs scale disproportionately with team size/structure. Developer productivity scales disproportionately with experience. How is it that so many companies can't do the basic arithemtic required to see the implications?
Management error #3: "This means keeping up-to-date with the latest trends in computing, programming techniques, and languages, and adapting to change."
This is not an error in itself. On the contrary, IME most older developers who are genuinely interested in their field do keep up (and find it far easier to do so than their younger and less experienced colleagues, since the tech industry doesn't innovate nearly as fast as the PR guys would like to pretend: older guys have seen a lot of it before, and can quickly identify genuinely new things worthy of further exploration and put them in context).
However, the error is in drawing this sort of conclusion based on the statement above: "To be writing code for a living when you’re 50, you will need to be a rock-star developer and be able to out-code the new kids on the block."
Almost everyone who is keen enough to still be coding by that age will out-code the new kid with his trendy tools and methodologies in his sleep.
BTW, I'm not an "old guy" in programming terms, and there's no bitterness here. I'm just a guy who watches this sort of debate from the sidelines, wondering how so many supposedly smart management people can be so utterly, obviously, incredibily dumb for so long, and still not get it in 2010.
This is much less the case at companies that are tackling hard problems though.
Immediately after the sentence you cite, the OP says "Build skills that are more valuable to your company, and take positions that can’t be filled by entry-level workers"
Management roles may be one option. You are correct that technical competence doesn't imply management competence but that can still be learned (over the course of one's career).
I do understand the rest of your points though.
ETA: You say ... can anyone cite me a single source that justifies this position?
Exactly what kind of citation would you need? You can probably look at successful companies and see how they handle the problem.
It is the implication that newly learned management skills are "more valuable" than high-level technical skills that I question. I'm not saying a good manager isn't valuable; on the contrary, I think good management is essential. I'm just saying it's a different, parallel track to technical work, but a lot of people (particularly not very good managers) seem to see it as a technical track that stops at about the level where the management track starts.
Firmly agree and I'll go a step further. I think the traditional org structure and traditional titles aren't well suited for emerging technologies.
Fact is, whoever is held responsible for succeeding/failing is going to get paid more. Being held responsible sucks and is hard.
I think a reasonable alternative would be smaller, largely decentralized teams that don't have traditional management, instead having two people they interface with who take over the traditional management roles - a logistics/supplies guy who checks what each team needs and makes sure they're equipped, and a planning/coordinating guy that makes sure the technical team has something sort of resembling a plan that fits in with the organization's grand strategy.
Team size would be 3 to 10 people or so, with one logistics/supplies guy and one planner/coordinating guy checking in with 5-10 teams at regular times and being on call during certain times if needed.
Something like that. As long as you've got a manager and he's held accountable for results, he'll have higher social status, be more neurotic, and expect to be paid more. I think moving to a supplies/logistics guy (similar to a servant manager type) and a planning/coordinating guy (strategist/diplomat/mediator) you could build an organization where engineers had more respect and authority and seniority, but things would be kept in check. There'd still be some friction between your planning/coordinate guy and technical people, which is natural, but ideally less so and there'd be more of a push for good engineers to lead a new team working on a new project than to become middle managers/planning guys. Largely different skillsets, engineering and planning/coordinating. Google Wave is a pretty good example of why you need a planning/coordinating guy and not just a pure engineering project, but engineers should have the most authority, social status, and prestige in a technology organization.
Indeed, but let me ask you this: what real responsibility do all those layers of middle management in a typical big software company actually have?
Detailed planning of individual features is junior management stuff. The only estimates that are really worth a damn come from the junior managers, based on the technical data provided by their teams.
Strategic product and project management -- what products and major functionality are going to be built and when they will ship -- is senior management stuff. The technical decisions that really matter are taken by senior managers or executives. Are we going to drop major projects W and X but include Y and Z, given that this means we can ship a new version of this product in Q3? Shall we authorise a 20% increase in payroll budget for this product's team, given that this would allow us to include project Y by that deadline as well?
Obviously in a large organisation with many products, each of which is itself large, there is scope for having layers of management in between so everyone is working on a sensible scale. But you can scale out a pretty long way with just a single layer containing just a few extra managers, and I'm pretty sure that the 2/3/4/5/6 layers you often find in a lot of big software companies are mostly dead weight.
The ability to convert detailed specs into code is a fungible commodity. Management, architecture and design, on the other hand, are areas of software development where you need multiple complementary skills; technical ability, good communication, understanding of your customers and industry area, an ability to influence others, etc. People like that cannot easily be replaced, hence the higher price. In some cases technical guys appear to need those things too, but that's just because they're unofficially doing the job of an architect, manager or designer.
> Even though you may be highly experienced and wise, employers aren’t willing or able to pay an experienced worker twice or thrice what an entry-level worker earns.
Define wise. That sounds a lot like "capable of being an architect/manager/designer". If you're capable but resisting the promotion then I'm suspicious of your claim to deserve more money.
I agree with you that an experienced coder will be more productive than a less experienced one. But I would also say that 20 years experience will never make up for a lack of natural ability. I've interviewed programmers with decades of experience who failed the most basic of our technical tests (think FizzBuzz). I'll bet for every old timer who's excellent and just wants to stay a coder, there are 5 who are just below average and have never been offered a promotion.
I see the issue more as a failure by the good experienced coders to differentiate themselves in the marketplace than a conspiracy against old people. If you've been doing something for 30 years but all you're selling is "5 years python experience" just like everyone else then why should I pay you more? Tell me why you're worth more. Convince me you're lack of promotion comes from a passion for your craft and not just down to a lack of ambition or ability.
If you have a good programming language, the code should be the "detailed specs."
"But I would also say that 20 years experience will never make up for a lack of natural ability."
20 years of "experience" won't, but 20 years of dedicated practice will.
I strongly disagree. The point of a commodity, in the economic sense I assume you meant, is that one item is just as good as another. You pay a certain amount of $$$, and you get a certain amount of Stuff.
IME, one piece of code implementing a particular requirement is very much not the same as another. Assuming otherwise is the kind of naivety that leads managers to make the sort of mistakes we've been discussing.
> I see the issue more as a failure by the good experienced coders to differentiate themselves in the marketplace than a conspiracy against old people. [...] Tell me why you're worth more.
If you believe code is a commodity, you don't want to hear and won't believe the answer anyway.
As a coder, and somebody who loves the craft and identifies strongly with it, I "disagree" with this relationship ( as much as that is possible, since nobody asked me to vote on it or anything ) and I think it is dehumanizing. But wishing it away or romanticizing what we do, avoiding the fact that we are commodities just like every other worker in a corporate enterprise is just a terrible strategy for overcoming it.
I like what the guys at http://www.bettermeans.com are doing with the open enterprise governance model. I don't want human activity to continue the process of commodification, and this is a big step taken to change course.
I hope that my contributions to discussions like this will encourage others to do the same, and that maybe, if those people one day have employees of their own, they will be a little smarter than the managers of today and the industry will be better for it.
In the meantime, I don't see why we should place any faith in the established practices of managers who, as an industry, run more projects that fail than projects that succeed. Can you name any other industry where it would be considered acceptable by the market if over 50% of the products bought failed, even if the costs ran to millions? I sure can't, it's just that the management idiocy is so widespread in IT that the market seems resigned to the inevitability that whatever they pay for will be crap that doesn't work properly.
I think tech companies see this as the lesser of two evils. Would you rather lose a good programmer and gain a decent manager, or would you rather keep the good programmer and gain a PHB who will drag down the performance of that good programmer and their entire team?
Myth #1: People hire younger workers over older workers because of the money. This is not true. Think politics and psychology first. People who move up the management ranks often have political or social skill superior to technical skill. They slimly don't what engineers who are more technically savvy or not subservient enough around. Not so the young greenhorns or even immigrants. Competent, seasoned engineers can't be as easily manipulated.
There is no substitute to experience, no matter the spin.
And often the obsessive coders pay little attention to the office politics. This leaves them exposed to the career obsessed suits. Politics and human dynamics first, money distant second, as always.
As for your last point, http://www.jerrypournelle.com/archives2/archives2mail/mail40...; it's self evidently true.
This is when I like to point out that guys who were coding in Lisp or SmallTalk 20 years ago are looking at the "new" and "cutting edge" programming tools and languages today and wondering why it's taken everyone else so long to get here.
Now, traditionally, middle management has also made high-level technical decisions, which I think is just stupid. you should have technical people make those decisions, and /if required/ have the management types help interface with other stakeholders. Quite often the best people to make technical decisions don't have very good 'soft' management skills, and the people with the soft skills don't have the technical qualifications. (I mean, some people have both, but those people become very expensive, very quickly.)
Middle management does valuable work; the thing is, I think that the soft skills required to be a good middle manager are more common than the skills required to be a good front-line programmer, so really the management role should be done by someone who is paid less.
The question is, how do I carry this off? I mean, part of the managers toolbox is that they can get your ass fired... traditionally, management getting paid more has been part of the power dynamic that makes the programmer quit slacking off when management is nearby.
Some would say that a softer approach is better, anyhow; I mean, like it or not, you pretty much have to treat your programmers well; they have options.
1) Join a good big company like Google where experience is not disrespected. It is natural for startups to prefer good and cheap young engineers.
2) Face the reality, develop and respect soft (management, talk, people, emotion) skills besides pure coding skills. It is a fantasy that coding skill is superior to other skills. Everything is engineering: your job is solving-problems, not mere coding.
3) Start your own company and work hard on it at least once in your career. If it fails, you learn valuable skills other engineers cannot compete.
4) Beat the average. Going extra miles to become better every year (if not every day). You will be surprised how far you can go. Most average engineers will never go outside their comfort zones, thus peaked after 5 years into the career path. It means: contributing to an open-source project; writing a blog; creating several web applications; Learning new skills (Machine Learning, Web Design).
(One interview was very amusing where I slipped and started talking about working on PDP-11s and the guy exclaimed "How old are you?!?!!!".)
They generally believe they are worth a lot and should be entitled to everything they had when Nortel was at its peak. Unfortunately, they don't have relevant skills and are generally outmatched by new grads in programming interviews.
I find it both sad and enlightening. Having been the young guy who interviewed a lot of these, I certainly feel like I have a good clue on how to avoid it (don't become a lifer at an big'ol company).
I'm not just talking about stuff like NoSQL, but most had limited experience with relational databases. Not just a lack of knowledge around ruby/python but sometimes even java/c#. Web, css, javascript, mvc or any relevant high level pattern - forget about it.
So I guess, specifically, what they lacked with the general knowledge of web or mobile (what we largely hire for) paradigms, and then the entire technology stack (from view to storage) that accompanies it.
And the few who did have relevant experience, tended to be "experts"...certainly not able to go from html/css all the way to database design.
For the same reason the executives advocate immigration, they want ever greater supply of slaves to be discarded just when they start to understand the real game.
Experience over the last 14 years as a consultant, working with a few very skilled people in Russia, Brazil, India, Vietnam, etc. has convinced me that salary or consulting fees should be based on value provided, not location, age, etc. I offer a 60% discount when I work remotely because frankly remote workers are not as effective as having everyone in one location and I see little difference between myself telecommuting in the USA or someone equally talented half way around the world, assuming that people are willing to time shift their work schedule as needed. Age does not have too much to do with it either, except that I find myself unwilling to work long-term more than a certain number of hours per week - and this is probably common with older workers.
That experience means you don't have to pay for your worker to be spending half the day trawling google or api documentation to learn how to do x when they could be writing code.
You also pay for the code to be maintainable, well written, flexible, robust. An inexperienced programmer will write shitty code, no matter how good they think they are, regardless of the number of books they've read.
Finally you pay for experience within the same domain as your company's problems. I don't care if a guy's been programming since 12, there's a 99% chance they've never touched business software. They will not know the right questions to ask.
As for the 60% discount, if that's what gets you gigs, fair play.
But to offer it on principle? That's just bad business.
re: 60% discount just on principle: not the case. I have had a reasonable amount of customer feedback that they feel they get better value at the higher rate when I am on site. I would be curious if a good percentage of consultants are able to get the same rates regardless of working on site or remotely. One big win for me with my setup: I like to work early in the morning and often at night, and I like to hike during the day (I live in the mountains, 2.5 hours from the nearest International airport - fairly remote) and this allows me to work hard (and do a lot of writing) without burnout. That said, it is a lot of fun to work on site also, even if it cuts into my lifestyle.
You don't see a lot of startups full of old programmers dominating their fields. You don't see a lot of old programmers creating awesome open source projects. Not even from those who retired and have plenty of time on their hands. Many of the programmers who created great things 30 years ago are in positions to name their projects now, but what they've achieved since is less than when they were young and limited. Math and physics (the fields generally most like cs) show the same pattern: throughout history, most great work done by people under 40. None of this can be attributed to discrimination.
Certainly old coders feel as sharp as ever, with knowledge and experience tacked on. But how one feels is a poor measure of anything. Measuring overall talent is hard, and controlling for everything else so as to measure talent by age is harder. I haven't heard of anyone seriously trying.
It's a scary thought. Can anyone disprove it?
IMV, the it was the tail of of the baby boomers who could have started doing programming in anything resembling what we might have today, and they wouldn't/couldn't have started until at least the late 70s/early 80s. When 'home computers' started becoming commonplace, 'programming' started to become an accepted vocation. Those people are now approaching or in their 50s, and still have another 10+ years to go before 'retirement'.
Frankly, I don't see that many 'awesome open source projects' compared to the total number of projects launched/opened. What I value more are 'awesome open source projects maintained and kept current'. I don't see many of those around at all, by young or old people.
http://www.denx.de/wiki/view/U-Bootdoc/History
I've met Wolfgang and would estimate he is a few years older than me, which would put him in his 50s. He still is much sharper than the youngsters on the email list. :-P
My first computer was a TRS-80 Model I, bought in 1980 or '81. My first program was written in Basic on a timeshare system (dialup modem with a DEC terminal) in 1978 or '79.
Yes, there will be a point where your salary will not grow. But that salary is usually higher than most other skilled professions. (Note: this is an assumption; if I'm wrong, that would be interesting.)
My experience has seen very little "mastery" in programming; after about 5 years, most engineers hit about the same level of ability. (Note, I'm not saying you can't hit mastery of a particular thing, but that most don't do it.) Thus, there are only two kinds of programmers, skilled, and learning. If you don't gain differentiating skills after those extra years, why should you be paid for it?
Maybe this is the real "dark secret": most programmers don't know how to gain mastery of something useful to a business. Maybe this is what "we" should be worrying about, rather than hiring practices?
But there are skills past simply becoming proficient in new tools. You could "master the tool", like knowing the details of the JVM memory model, and very importantly, be capable of identifying very hard problems that you can solve that those "young guns" can't.
It is incredibly rare for me to find an experienced programmer that can sell anything but their past "obsolete proficiencies" to me. Most of them sell me on the fact that they've simply been good with X+Y number of tools, where Y of them are now no longer relevant. But they never focused on developing deeper skills that might have relevance (big data problems, etc).
It's the constant shift of tools that adds a lot of this tension. Yes, we need to be able to pick up new ones (languages, frameworks, etc) quickly, but if broad proficiency is how we define mastery, this has little relevance to businesses.
I'm not saying this is easy. How do you unambiguously describe a programmer's skillset past the languages and frameworks they say they know, especially in a way that might be "future-proof"? ("I optimized my system to display 30 frames a second!" "Wow, my phone does that now...") Ultimately, if we can't clearly describe why people's experience is better, it will be hard to justify paying them more, once you become proficient with that particular toolset. Thus, I don't sense real age discrimination as much as a simple inability to sell the value of our experience.
Of course, some programmers are WAY more valuable than others, so this is a problem that isn't just about age and experience. Hiring practices sure haven't matured at all during my 10 years on the job. But, until the finance guy can see why a guy with 25 years of experience but with 3 years with tool X is more valuable than the guy with only 5 years of experience but all 5 with tool X, well, you're not gonna see the money flow.
live on passive income
become a entrepreneur
become govt employeeI'm something of an extreme in that I was forced by finances to quit college after my freshman year and am about to turn 50, so it was a dozen years into my career before I started programming Windows (Charles Petzold C SDK level ... which I suspect is also not the sort of Windows programming you're talking about).
First, the 'suits' want only 'fungible', 'compliant' workers.
Second, the 'suits' do NOT want any workers who might have some technical qualifications that might be powerful, compete with the suits, and scare the suits.
Third, likely highly experienced, older programmers can get good work via 'body shops' around DC.
Fourth, one common tech personnel policy is to hire people as young as possible, promote 1% into management, and fire the rest by 35. In this case, the person 35 would have been better off starting a grass mowing service at age 18 so that by age 35 they have had 17 years in the business, expanded to landscape architecture, have 12 employees, etc. Or generally a Ph.D. in EE will be better off at age 35 having just gotten an electrician's license and built a nice collection of local customers.
Generally, in a technical field, it's important to need a LICENSE.
Generally the big, secret economic opportunity now in the US is to exploit a 'geographical barrier to entry'. So do well in a Main Street business where anyone more than 100 miles away can't be a competitor and do well.
It can commonly be better for a person 18 just to join McDonald's, work hard, learn the business really well, work up to a manager of one McDonald's, manage also a second McDonald's for the same owner, and then have a heart to heart with a local banker about buying and running their own McDonald's. Build up to 10 McDonald's, run them WELL, and will have a better job than nearly anyone in a company a programmer might work for.
Fifth, a good programmer should start and own their own business. E.g., really good at Web site design and construction? Fine: Do such sites for companies in a radius of 50 miles. There, of course, need to meet face to face with the customer and, thus, have a geographical barrier to entry.
Sixth, have some deep technical qualifications, say, from grad school? Fine: There's nearly NO WAY anyone else will construct a good job for you. So, start and run your own business based on the deep knowledge you have.
All of those issues are company-specific. Sadly, most companies have at least some of the problems.
And I find your McDonald's story insulting: talk to me after you run one a single McD's by yourself and then you'll be able to convince me that a programmer should get paid more.
Dealing with people is hard. Dealing with short term employees is harder. Dealing with people who don't have skills to work higher up the employment chain is even harder. Doing it through two levels of surly middle management would give me an ulcer.
So are there multi-McD's owning entrepreneurs who make more money than me? Hell yes. And they deserve every penny. It's a harder than sitting down in an Aeron chair, staring at 30" monitor and trying not to drip the condensation from your iced coffee on your MacBook Pro.
If are one person short on a shift, then lose revenue. One person long, then waste money. Getting the staffing right, for each shift, for the year, is a LOT of money -- add it up yourself.
Net, there's a LOT of difference between running a good fast food restaurant and not. So, someone who knows how to run 10 such restaurants can be getting annual cash income over $1 million a year, with a VERY stable job, where they can't be fired and where they can bring their children into the business. Go to a yacht club, and it is mostly such people you will find.
The blunt point is, in the US, some of the best opportunities remain just doing well in a Main Street business.
Then, if some computing expertise can help, still better. But, generally in the US, getting away from just owning a Main Street business is a risky career direction.
Now imagine that you partner one of those with someone who has technical skills in data mining, expert systems, and real-time data feeds. They build a system that watches local events, checks the weather feed, looks at traffic, etc, and predicts likely sales and staffing needs. Heck, it could even call the employees in to work while the manager sits on his yacht.
This lets several marginally profitable McDonalds owners suddenly start living the high life on $1M/year. The software might cost say $100K, quite a reasonable price if it saves at least that much on employee costs. There are 12,000 McDonalds in the U.S. The software engineer and his McD's partner are now head of a company doing roughly $1.2B/year in revenue, and there are maybe 10,000 newly-minted millionaires out there.
Any experienced McDonald's managers looking for a technical cofounder?
Buried in the middle should be a little integer linear programming for the scheduling!
The 'qualitative' stuff about the impact of weather, high school events, etc. would be more difficult, and it may be that something like an expert system would work -- typically there's not enough data for some clean statistical attack so that some expert judgment might be essential.
Uh, the $1 million a year would be for someone owning 10 McD's, not just one!
Cute.
One potentially nice part of this could be the point of sales terminals: They may have been recording data on each Big Mack, fry, etc. along with time and date. Good data to have.
You're both saying that the owner of the McD's will earn more money than the programmer, and that this is absolutely fair and reasonable.
Is this easier or harder than founding a successful software business?
But my advice is still own your own business. So, have a Main Street software business or some other software business but OWN it yourself.
If you don't own it yourself, then you may be better off working your way up to owning 1, 2, ..., McD's yourself.
However: I know lots of 50-something developers who have no problem maintaining employment and contracts. They are top-notch; their skills are current and their proven track record and accomplishments are what get them gigs. Companies want them because they're less of a risk -- instead of guessing whether the young guy will develop the right skills, they can take much less of a risk and get someone who's already proven himself.
There are a lot of subdomains within programming. Mastering things like Unix tools, patching certain web servers, knowing the kinks of specific RDBMS and/or filesystem, how to design batch processing, makes you a lot harder to be replaced by those 20+.
Not all 20+ guys are hacking on PyPy or Firefox. Most of them are Rails/PHP warriors. Competing against them is a lot easier if you master skills that can only be obtained by experience.
Here's a big secret, it isn't a struggle for older people to keep up with younger people. It is actually easier for me to pick new technology, or languages now than when I was a 20 year old programmer.... And I'm able to take responsibility for projects and order of magnitude more complex.
I always believed that when I got into the position of hiring people, I'd hire younger people because when I was younger the companies were all seemingly snobby about experience. But when I got into that position, I discovered that it was all about hiring people with presence, perception and perspective. Assuming the candidates can program, their ability to make good creative decisions is what determines productivity. Far more than experience sit any language. Any programming language can be learned in a short time... Perceptiveness is hard to teach.
These qualities themselves are too rare to waste time discriminating on age... These qualities, I think, are more common among older programmers, but there are more younger programmers interviewing....so I can't really say, and admit that is a prejudice. At any rate discrimination on any terms not related to doing the job is counter productive and stupid. I find someone with the qualities I'm looking for, I don't care about the age, or anything else.
The HR system in America is completely broken. Part of the reason is that nobody knows how to measure developer productivity on a corporate level. I've seen youngsters who put out huge amounts of buggy code praised which youngsters putting out slow, carefully designed code were told to emulate the "rock star"--- but it was painfully obvious that the rock star was slowing the project down by causing damage everyone ewes was spending a lot of time repairing.
Meanwhile, i once had a "recruiter" refuse to send my resume on a java position because the previous java shop I'd worked at had used oracle 8 and this new shop "is really looking for oracle 9 experience.". -- it doesn't matter what version of oracle when your job is to write code to process the data delivered by the db connector. But the company listed oracle 9 and she, who knew nothing about programming, felt she needed to screen out those who were unqualified. She was unqualified to do her job.
Almost never have I been on an interviewed where they actually checked to see if I was qualified competently. And universally the ones who did, didn't ask me to write code for them. Again, correlation is not causation.
But what we have is cargo cult HR - confusing experience with competence. It probably took 20 years to be a great machinist and you got valuable every years. You get more valuable every year programming, but you don't measure that value by whether someone knows erlang or haskal. Either one will do, even if your codebase is in erlang.
For me starting startup was one of those burn-the-boats decisions. I was a victim of age discrimination, after being hired, in face, I was let go for my age. Of course they wouldn't tell me that, and they wouldn't tell me why, but the said they'd give me a sterling recommendation. It was obviously age... And I vowed to never need that recommendation because I was damn certain I'd never leave my livelihood in the hands of another idiot who knew nothing about technology but thought he could manage programmers or a startup. I was happy to see that startup fail..... And so far, I haven't failed.
Age discrimination happens, and it is one of the profoundly broken things about our industry. When I started, i saw a lot of it happening to younger programmers. I saw zuckerberg advocate it public ally against older programmers.
But it is counter productive.... And a sign of being a bad work environment.
I suggest everyone take into account the age of the people at companies you interview at. Even if you are 20, if they don't have a single engineer in their late 30s, beware.
What they did the companies who actually checked your competence ask you?
Ask them how they like to work, do they like big projects or small ones? Do they like to work alone or in groups? What kind of reference material they like to keep handy. All of these can be phrased as sort of "how can we best support you as an employee" questions, but they will tell you a lot.
http://news.ycombinator.com/item?id=1642069 http://news.ycombinator.com/item?id=1642075 http://news.ycombinator.com/item?id=1642072
Chill a bit. Even if the trolling has gone both directions to some degree, feeding it doesn't improve squat.
I've had the privilege to interviewed potential hires. It's always fun to ask why they put down java/javascript on their resumes. Point being, we have all dev job applications come to someone on the dev team. We know what to look for, why let HR mess it up? From our point of view it has nothing to do with your age & everything to do with your skill set.
IMHO asking canned interview questions is not the best idea. Ask them "what are you currently working on". Then ask them to write code in that language. Start with simple things like a loop and go from there. You can learn a lot by seeing how they do it. If they have done any kind of open source code thats always a huge plus; you get to see the code before the interview is scheduled, always nice.
It is almost the same story as with foreign laborers, who will accept almost any terms, that are slightly better than at their home, and they already got motivation and taken risks.
Young, inexperienced people are much easy to manipulate and control, due to their naivety, lack of market understanding and inexperience.
The same practices are used on campuses, where some professors agitate students to get a part-time jobs or a test-task, with very low, or even no payments et all, while they're collecting the result and creating products for profit.
Generally the venture partners do not know how to build significant businesses. Look at their backgrounds and see why. Compare with people doing significant work in technology for, say, the US DoD.
My guess is that the IPO market remains open for a solid company -- good market position, plenty of revenue and earnings, good record of earnings. But there have not been very many such companies built, even private where SarbOx doesn't apply.
My take is that we need to do better at building solid companies. I'm trying. I know some people I'd like to have on my Board, but I don't see any in a venture firm. Sorry 'bout that.
This should be "the best of times" due to a 1 TB Seagate drive for $60, an Asus mobo with a dual core AMD for $100, plenty of GbE, fantastic 'framework' software -- I'm using .NET and find Visual Basic .NET to be fine. I use the compiler just via command line and think it's fine.
The US just needs to do MUCH better at building significant new companies. I've heard that SarbOx costs about $1 million a year for a company to follow it. For a significant company, okay.
Just how VCs are going to get an exit with Facebook and Twitter I don't know.
There is a Great Recession out there, but I sense that there is also a LOT of cash 'on the sidelines'.
I've heard it costs something more like $2.6 million, but it's going to be company specific and the cost might have come down as people and accounting firms got experience. However the pure $$$ cost is only a portion of its total expense, it's also a time and attention sink and it significantly increases the liability (including as I recall criminal) exposure of some of the company's officers. Plus it costs a LOT of time (a year or more), money and attention upfront to get your company SarBox compliant for an IPO, and too much of it is insane stuff that does nothing to improve your real business.
If you remember your chemistry, look at it as raising the activation energy needed for a reaction.
Agreed this should be "the best of times", but you're still talking about fairly small scale and limited domain areas. As I keep harping on, where's the next FPGA like thing going to come from? The only really big "new thing" hardware based startups I know about are Tesla and Space X and they were funded by a single angel. Who got his money from co-founding PayPal, which was a perfect fit for eBay to acquire, which is a prior to SarBox public company.
I don't really know about Twitter (but it's tiny in terms of people and revenue, all out of whack with its impact), but Facebook has clearly made a decision to stay private for whatever reasons. It could go public, investigating why they've decided not to might be worthwhile.
The cash on the sidelines is a good and big question. Some say it's not so much at net, i.e. companies are keeping it to make sure they can service their debt (unfortunately debt is massively tax advantaged compared to stock based capital), others say (and this is clearly related to the first point) that it's being held in reserve for the Dark Times To Come. Or at least fear of such.
There have been too damn many 2,500 page pieces of unread monster legislation passed with no end necessarily in sight (let's say that confidence in what the Republicans might try to accomplish when they get one or both houses of the Congress back is not exactly high) ... in times of colossal uncertainty keeping reserves can mean the difference between your company's survival and death.
E.g. will the insane file a 1099 for any corporate recipient of $600 or more per year insanity be repealed? If you're a small business (< 500 employees, half the economy), well, you best keep some reserves in case you have to do that (it will cost a lot of money and friction, and will likely cost a lot of companies business as everyone decreases the number of companies they do business with).
Etc.
At the furthest extreme, compare to 1937 when "capital went on strike"....
People can't control their age so there is an inherent insecurity there. Combine that with a small amount of actual discrimination and confirmation bias; now you have a "dark secret".