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.

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.

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).

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).

For the same reason the executives advocate immigration, they want ever greater supply of slaves to be discarded just when they start to understand the real game.

Experience over the last 14 years as a consultant, working with a few very skilled people in Russia, Brazil, India, Vietnam, etc. has convinced me that salary or consulting fees should be based on value provided, not location, age, etc. I offer a 60% discount when I work remotely because frankly remote workers are not as effective as having everyone in one location and I see little difference between myself telecommuting in the USA or someone equally talented half way around the world, assuming that people are willing to time shift their work schedule as needed. Age does not have too much to do with it either, except that I find myself unwilling to work long-term more than a certain number of hours per week - and this is probably common with older workers.

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?

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?

    live on passive income 
    become a entrepreneur
    become govt employee

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.

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.

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.

It is almost the same story as with foreign laborers, who will accept almost any terms, that are slightly better than at their home, and they already got motivation and taken risks.

Young, inexperienced people are much easy to manipulate and control, due to their naivety, lack of market understanding and inexperience.

The same practices are used on campuses, where some professors agitate students to get a part-time jobs or a test-task, with very low, or even no payments et all, while they're collecting the result and creating products for profit.

Generally the venture partners do not know how to build significant businesses. Look at their backgrounds and see why. Compare with people doing significant work in technology for, say, the US DoD.

This is much less the case at companies that are tackling hard problems though.

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.

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.

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.

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.

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.

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.

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?

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.

Is this easier or harder than founding a successful software business?

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.

What they did the companies who actually checked your competence ask you?