Silicon Valley's Dark Secret: It's all about Age(techcrunch.com)
techcrunch.com
Silicon Valley's Dark Secret: It's all about Age
http://techcrunch.com/2010/08/28/silicon-valley%E2%80%99s-dark-secret-it%E2%80%99s-all-about-age/
26 comments
"Experience is the name everyone gives to their mistakes." --Oscar Wilde
That's not just Silicon Valley's dark secret. It is pervasive in the industry.
Counter-anecdote: I just got rejected from a startup because I was too inexperienced, despite having 4+ years of professional experience under my belt. They said there's no reason why I wouldn't be awesome, but I've just done too little for them to know for sure.
Your not the mid-30s programmer, your the mid-20s programmer. The drop off happen after your mid-40s.
As far as I can tell the drop off starts in the mid-30s and is very strong by 40 (which also just happens to be where one can file an age discrimination lawsuit which is nearly impossible for not being hired but much easier for being fired). And that's what I personally noticed in the D.C. area in the '90s due to fortunate genetics (until about 49 and 1/2 a few months ago when I started to get some gray hairs I was still frequently being mistaken for a lower 20-something college student): at a certain point it became a lot harder to find work until I got a clue and scrubbed my resume of all evidence of how old I was.
(One interview was very amusing where I slipped and started talking about working on PDP-11s and the guy exclaimed "How old are you?!?!!!".)
(One interview was very amusing where I slipped and started talking about working on PDP-11s and the guy exclaimed "How old are you?!?!!!".)
If you're young and sharp, programming looks like paradise. It's more or less a meritocracy, there's a ton of personal freedom, and you get to spend your days doing creative, challenging work and getting paid fairly well. You may not have even had to slog through 4-5 years of college.
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.
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.
We all compete with people who will work 60 hours a week for half our salary. Words cannot express how much I disagree that "knuckling down and doing your best" is a sustainable competitive position. Do it better than they do. Do it measurably better than they do. Do it ridiculously better than they do. Widen the scope of "it" to include a skill not on the menu at RentAResource.com, then do it. Market your doing of it better than they do. And, finally and most effectively, own the effing company.
Do it ridiculously better than they do.
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.
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.
> That sounds nice on paper, but there are a lot of extremely talented and productive young programmers on the market now.
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.
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.
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?
I don't. I just don't assume I'm superior either.
I don't. I just don't assume I'm superior either.
So that's when you do things ridiculously different than other people. If you fail, you've still got this baseline of skills to fall back on, and you're indistinguishable from everyone else. If you succeed, you're very much distinguishable from everyone else, and that's worth a lot of money.
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.
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.
Agreed. That is my current plan exactly. I'm heading off for 3-6 months in SE Asia to spend travelling, living cheaply and studying math & machine learning with the goal of coming back to the States later to either pursue a graduate degree or a gig doing ML/analysis.
Can any of them reliably find SQL injection, write a fuzzer, or spot an integer overflow? I'll pay you multiple thousands of dollars to refer them to me.
If not, re-read Patrick's comment with that in mind.
If not, re-read Patrick's comment with that in mind.
I only know the basics of these (SQL injection and integer overflow for kicks in high school, dumb context-aware codec fuzzer for a memory allocation bug in FFmpeg), but I'd like to take your quiz to see what I'm missing. I'm co-teaching NetPen at Northwestern this fall and want to know what I can focus on.
I'm turning 21 in a couple months, for whatever it's worth.
I'm turning 21 in a couple months, for whatever it's worth.
Email me, and we'll figure out a good time for you to come buy and visit; I'll buy you coffee. We're super easy to get to.
Plenty of them can. I've worked with several myself. As you might expect, they don't need jobs. I worked with a 20-something at my previous job that was as productive on his own as some entire teams.
If they are making 60k a year, you can make several thousand dollars right now by getting them a rather large pay raise. Otherwise, re-re-read Patrick.
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.
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.
I know several 20-somethings making well over 100k/year coding and managing teams of much older engineers. For the most part they got the domain expertise that implies doing real research in top undergraduate CS departments, but they do exist.
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.
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.
You're doing a really good job of evading the point here.
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.
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.
A lot of senior devs are making that kind of money not because they are domain experts but because they have been in the same spot collecting raises for a long time. Those are the kinds of people my warning was intended for and I think a lot of these people wildly underestimate how hard it would be for a bright young somebody to walk in and do their job.
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.
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.
It should cheer you substantially to realize that you have come around to what I believe Patrick's way of thinking has been all along.
I don't think we were in substantial disagreement to begin with. I just don't find language like Do it ridiculously better than they do. to be very useful. Certainly English superlatives have lost most of their punch at this point but for most people their best isn't going to be ridiculously better than everyone else's.
Next time, read the comment carefully before fixating on a single word and starting an unproductive argument. I know it's hard; I do it all the time too.
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.
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.
That's assuming you're doing the same thing you used to do 20 years ago.
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" ;-)
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" ;-)
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.
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.
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.
> ompeting neck & neck with people twenty years younger willing to work 60+ hours a week for half your salary
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.
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.
Salaries don't only compensate for performance, they also compensate for responsibility.
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)
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)
Hi, thanks. I completely agree, if you have been given more responsibilities, that should (in theory) imply that you're good at what you do and so your hours are worth more than the average (I didn't just think of performance, but value in every sense). That's something else than just scaling salary with age though, or?
> Shouldn't salaries reflect the value you provide to your employer
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.
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.
Ideally, things should work that way.
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.
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.
I'm pretty sure that at least some companies compensate for negotiation skill at annual raise time. Google, for example, tries to normalize salaries by performance & job function when they grant raises. So if you're a really good negotiator and managed to get a salary much higher than your equally-performant peers, your annual raise & bonus will be less than if you're a really good programmer but suck at negotiation.
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.
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.
Negotiation skill and how desperate you are. Some will do anything to get a foothold in The Land of Opportunity, while others are already there and can afford to wait for a better offer.
The variation in productivity between programmers is somewhere from 1 to 10 to 1 to 100 (although I like to point that for a certain level of problem difficulty there's a cutoff below which productivity is 0 (ADDED:) ... and then there are those who's contribution to the organization is negative, but that's a different problem...).
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.
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.
> The variation in productivity between programmers is somewhere from 1 to 10 to 1 to 100
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.
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.
You're very correct and I added a note to that effect apparently while you were composing your reply. And your point about the easy problems is really important to highlight (and wasn't one I was thinking about).
The question I have about these 100x (or 10x) productive programmers is why they wouldn't jump ship on employment and sell their 100x productivity on a project basis? Presumably they would make multiples of their salary if they are really multiply productive.
Some of us did. As a contractor, you certainly can earn a significant multiple of the hourly rate you would make as an employee in most companies. If you set up your own business and build your own stuff, then you have almost astronomical potential: the software development business has low barriers to entry, and the right idea can scale from a small team to serving thousands or millions of customers.
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.
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.
A lot of us including myself just don't have what it takes to work on a multi-client consulting basis. Plus at least back before the net became really big Gerald Wienberg said that the correct hourly basis to set is 5-6 times what you want to earn because of all the overhead and downtime that comes with this business model. That's still a factor if you're charging on a project basis, which is extraordinarily dangerous in our field due to the inability of our customers and ourselves to correctly scope a project before it starts.
> we'd see some people making 10, 25, 50 times as much
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.
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.
I think it depends how you define "effective" and "performance."
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?
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?
I agree. Salaries should correlate more directly with performance but in a lot of companies you steadily collect your yearly raises and after a while they add up. This can be very dangerous for people in tech though. In fact I just left a job after ten years of steady raises because I felt I was stagnating. I'll probably take a considerable pay cut in my next job but I think staying put would have been a lot riskier in the long run.
At least I'm not chained to an S.F. mortgage that means I can't live on < $90k/year.
At least I'm not chained to an S.F. mortgage that means I can't live on < $90k/year.
Unfortunately, you're wrong. Salary really only affects the upper limit of how much you're willing to pay an individual.
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.
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 thought that this was one of the better articles published via Tech Crunch lately. I would be interested in reading more articles from Vivek Wadhwa and highly encourage guest writers on Tech Crunch.
I personally found some of his previous articles on TC better than this one:
http://techcrunch.com/author/tcvivek/
I suppose programming as a particular profession may have this dark secret; I'm not a straight-up developer (meaning I'm an IT generalist who does develop but usually has some sort of hybrid job including mgmt).
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.
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.
Observing older programmers within my circle, they tend to master a few specialized skills that's hard to get from the hardcore and enthusiastic 20+.
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.
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.
Don't rule out the embedded world either. Lots of gray hair there.
This is key. There may be some professions in which you can kick back and slack off after 40 but programming is very much not one of them.
How many of them are normal, full time permanent employees vs. contractors? The major issue I perceive here is that things are ugly for people wanting the former and many aren't cut out for doing the latter.
They're mainly contractors, by choice it seems. But as far as I'm able to tell, things are ugly for anyone who wants to be a perm employee these days.
Choice or necessity? As far as I can tell, if you want to keep programming with anything resembling good odds you can make a major name for yourself, become a multi-client consultant, specialize in embedded programming or get a serious government clearance. I suspect your example is survivorship bias with the 2nd option and perhaps some of the 1st. The ones who didn't chose contracting (and didn't get into either of the last two options) probably just aren't programmers anymore. The official statistics (age vs. profession) suggest as much.
It's really more about how long it's been since you learned new stuff. Lots of programmers in their 40s learned most of their skills writing Windows apps and, at least the ones I know, are very resistant to change. If you just looked at older programmers who are open-minded and still learning then the numbers might be different.
Maybe it's that subset. Windows 3.0 was released in the middle of 1990 and it took a while for it to get red hot. Lots of programmers "in their 40s" should have "learned most of their skills" on earlier technology, e.g. UNIX and MS-DOS. Or mainframes.
I'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).
I'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).
To the extent that this reflects material reality, it suggests that there is an arbitrage opportunity for anyone who can get a babyfaced twenty-something to front for a team of 30+ year veterans with deep domain expertise and 10x productivity. All you have to do is have the consultant bios note their WoW habits and 7 weeks of professional experience with Merb and Cucumber testing.
Steve Jobs noticed this arbitrage opportunity -- and exploited it. He got himself hired to design circuit boards for Atari, farmed the work out to Wozniak who did the actual design, agreed to split the earnings and lied to Woz about how much he actually made.
Ah, yes, “Potemkin Consulting”.
Not the best metaphor since it's not hiding that there's nothing behind the facade, rather there's something superficially unacceptable behind it. Trojan Horse is not quite right (the experienced veterans are not going to leap out from behind the facade and ravage the hiring company :-) but something in that direction would be much better.
LOL - thank you, you just gave me a great idea ...
This vastly undervalues knowledge and experience. Maybe a graduate can compete in the day to day work of programming but over the long term of projects that extra knowledge and experience is going to help, assuming the senior programmer is constantly learning. It would be true to say programming in general isn't one of those professions where you can learn your craft and then spend a career applying it.
So, we should be taking care of our own career growth? Shocker.
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?
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?
All that said (and a lot is certainly true (except you're leaving out the unskilled and/or unlearning types of programmers :-) ), it's widely perceived that there is serious, unreasoning (aside from cheaper salaries, which is often a false economy) age discrimination in our field and that it's particularly strong in Silicon Valley. Doesn't matter if you're skilled and learning.
Most programmers definition of "highly skilled" is more like "proficient with a language", or framework, etc. A lot of people I know aim for "can use stuff" rather than "master this thing", which is mostly because, hey, it's technology, and there's always a new thing.
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.
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.
Management error #1: "Move up the ladder into management, architecture, or design"
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.
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.
I think a lot of this makes sense when you realize that the typical tech company isn't really trying to do something that's very difficult. The average internet company is chasing some gimmicky take on social marketing or a trivial mobile fad etc and your ability to succeed in that kind of environment is going to depend more on your ability to work corporate politics than your technical skills, unless you're absolutely incompetent.
This is much less the case at companies that are tackling hard problems though.
This is much less the case at companies that are tackling hard problems though.
I agree with much of what you're saying, but I don't think the "typical" tech company is anything close to the HN stereotype web start-up. Most tech companies -- and almost all successful tech companies -- are not just implementing some obvious, trivial web/social/mobile service and hoping to luck out on a quick acquisition.
That's probably true. I think what I'm saying holds to a large degree within companies too. For instance, you're probably going to have fewer opportunities to distinguish yourself by ability if you're administering mail servers at Intel than you are if you're doing chip design.
I have pointed this out in a comment on this thread but would like to repeat it in support of your list.
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.
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.
While I suspect you're correct in your first point, why can't both be true (control and money)?
As for your last point, http://www.jerrypournelle.com/archives2/archives2mail/mail40...; it's self evidently true.
As for your last point, http://www.jerrypournelle.com/archives2/archives2mail/mail40...; it's self evidently true.
"(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)"
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.
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.
> 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.
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.
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.
> Fact is, whoever is held responsible for succeeding/failing is going to get paid more. Being held responsible sucks and is hard.
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.
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.
Your comment on #1 above doesn't make sense to me.
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.
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.
> 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"
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.
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.
this is something I'm currently experimenting with at my company. My theory is that most of the management role can be done by empowered secretaries. Keep track of shit. Kick our chairs, make sure we are actually working on what needs to be worked on and not distracted by shiny. Talk to people and make them feel better when there is social bullshit.
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.
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.
> "Move up the ladder into management, architecture, or design"
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.
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.
> The ability to convert detailed specs into code is a fungible commodity.
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.
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.
I love that you're fighting the good fight, but to these people who run things, code is in fact a commodity and so is the person producing it. From the owner's perspective you buy coders low, you maximize their output and sell it high, accumulate the difference, and repeat. If you're a more liberal owner, you buy them free lunches and build up a "culture", let them wear sandals, send them to conferences, tell them they're not little units to be counted, but at the end of the day these pretty lies are just costs -- costs, which may or may not yield profit over the long run.
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.
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.
Oh, I understand the problem; it was "management error #2", I think. And I understand that discussing it here will have little real impact on the managers concerned. I got off that train personally and no longer work as anyone's employee.
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 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.
"The ability to convert detailed specs into code is a fungible commodity."
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.
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'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."
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?
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?
I don't get why someone who is older should get/expect a higher salary, all things considered. To me, it seems like this should be a free market thing. And by free market I mean on a global basis. On the other hand, I am in my late 50s, and I don't think that I have ever suffered from age discrimination (but who knows).
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.
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.
Experience.
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.
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.
Hello Matt, I agree: experience factors heavily into value.
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.
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.
Here's the real story:
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.
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.
Go find a better company to work for.
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.
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.
You do realize that the two of you are in violent agreement, right?
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.
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.
When I was an MBA prof, one of my students was running a Wendy's, in Columbus! He explained some of the opportunity: Watch staffing CAREFULLY. To do this, more than once a day, watch the weather, various public events, say, a high school football game, or anything and everything else that can affect traffic, Then staff accordingly.
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.
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.
That's an information problem, though, right? A McD's manager uses information and domain knowledge they have to lever up efficiencies in the business. They're every bit as much of a knowledge worker as a software engineer.
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?
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?
Nice. Then sell to Wendy's, Burger King, Domino's, and Pizza Hut.
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.
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.
"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."
Is this easier or harder than founding a successful software business?
Is this easier or harder than founding a successful software business?
Software is a big, HUGE advantage.
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.
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.
Age discrimination is standard: The subordinate is supposed to be younger. Period.
I remember hearing about a Korean company that changed a CEO for a younger one, and they fired everybody who was older than the new CEO.
Also over the past 10 years, venture capital in Silicon Valley lost money.
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.
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.
While I don't agree with your general point those are things with have always been true. For the last 10 year period I can't exactly blame the venture partners for SarBox ending the IPO exit (as another article has noted, in the last ten years there have been fewer > $100 million exits than there are VC firms). Add in the dot.com crash which started a bit before SarBox and the Great Recession and it's no surprise the industry has lost money. Or that we have every expectation it will continue to as it radically shrinks. The great 1958-2002 VC experiment is over.
Sorry, that should be "While I don't disagree with your general point...."
I can't judge the impact of SarbOx.
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'.
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'.
SarBox is considered to be the last nail in the coffin, not the sole cause of seems to be the effective end of the US IPO. The numbers speak for themselves, although of course a return of more than a couple of handfuls or so of IPOs per year would change that (less than that when you just count tech firms).
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"....
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"....
Zuckerberg advocated age discrimination outright from the stage of startup camp 2007. Of course at his age, he doesn't know any better.
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.
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.
We have engineers in their 50's; as the youngest on the dev team at my work, I'm getting closer to 30. It's nice working with a bunch of x-Microsoft guys (people who started in the early 1990's there).
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.
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.
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.
What they did the companies who actually checked your competence ask you?
What they did the companies who actually checked your competence ask you?
That was a side point, not really fully expressed. But part of the point I was trying to make is that there's no secret interview question and no trick questions. The best ones have been interviews where we talked about a problem they were working on. The best interview question is to tell the prospect about what the company is doing and the assumptions behind it, and see what questions they ask, and then go from there. Ask them about a hobby, ask them about anything that interests them. The important thing is to get them talking. In doing so you can find out how they think. Don't ask trick algorithm questions. (Got asked one of them 6 times in a row once because it was apparently the fad that year. )
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.
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.
Thank you. This is exactly the kind of thoughtful, quality post that contributes positively to the discussion.
You should try it sometime.
Someone has a vendetta.
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.
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.
This article fails to mention the most important factor, even more important than the money. Often people who advance to the management rank have the political skill or fund raising skill superior to their technical expertise. They simply don't what experienced engineers around who can see right through their bluff.
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.
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.
Seems to have missed 'sell your lifestyle to impressionable kids'
Does age discrimination exist? Yes. To the degree everyone fears? No.
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".
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".
Is anyone willing to think about the opposite hypothesis? Maybe programming really is a young person's game.
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?
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?
I'm not sure we're at a point in the evolution of programming having been a viable career path for enough people yet to judge one way or another. There's not many people in their 60s who have been professional software developers most of their career, so you wouldn't (yet) see a large number of retired people "creating awesome open source projects".
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.
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.
Das U-Boot http://en.wikipedia.org/wiki/Das_U-Boot was created by experienced engineers (I don't know about Magnus Damm, but Dan Malek is still in the engineering world - Sr. Scientist at Mentor Graphics). Wolfgang Denk took over the original U-Boot code and has been driving it forward for over 10 years now.
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.
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.
Possible solutions:
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).
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).
This is just the typical youth Vs experience dilemma. Older programmers - assuming that they keep up with newfangled trends - probably have quite a cushy time compared to other types of engineer, such as electrical or mechanical.
This is seriously noticeable in other places as well. For example Ottawa. The place is over flooding with vast quantities of old engineers from the likes of Nortel. They come into job interviews with most of their experience dedicate to archaic languages and platforms invented for and at Nortel.
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).
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).
What relevant skills did they lack, specifically? Was it just the particular programming language you use, knowledge of how to design and architect systems, development methodology, algorithms...?
It was a slew of modern stuff..none of which, on its own, is particularly hard to learn, but between someone who had been doing something else for 20 years vs someone who had been doing it for 6 months...the 6 month guy was always more appealing.
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.
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.
It is not about age itself, it all about motivated, young software developers who will accept minimum wage.
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.
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.
I think programmers should plan to retire by 40. Subsequently
live on passive income
become a entrepreneur
become govt employee