It's how our society is wired. We view the managers with clean hands and several layers of abstraction away from the gritty details as the very top of the food chain. Fast food franchises profit from this phenomenon by naming their employees "managers" and "assistant managers" to obfuscate the fact that they are employed in job that is quite low in the social ladder.

Just yesterday I interviewed a young developer for an open position we had. We came to the usual part of the interview where we ask him about his ambitions and future outlook. He was quite convinced that a managerial role was at the end of every successful developer's career, and had no concept at all of any technical rank higher than team lead.

You are less empowered as a developer than you think. I think this is one of the reasons people leave the position. You have very few levers of power and are pushed to do things that you think make no sense, but that serve the needs of managment. Eventually you despair and realise that you might be able to improve the decisions made if you yourself join the ranks of management. By the time you realise your mistake and want to go back, your skills are outdated and you are stuck.

It's also a balance from both a manager's and a developer's perspective to achieve the following:
- keeping the developer happy by letting them use new technologies which they will find interesting and improve their CV whilst adding value to the project
- keeping the manager happy by restricting what new technologies the developer can use because often the 'old' technologies are good enough for what is required and have less pain in the form of setup, integration and steep learning curves

I bailed because I became fed up of wasting a lot of my time learning about future technologies only for them to become abandoned because a different technology became the new standard. Other than low level C++ and T-SQL, what (tech) skills from 10 years ago are still valid today, hardly any.

I think the old versus new programmer is aptly described by the Woody vs Bud Light Year scenario.  I've seen it a couple of times.  And then when Woody realises he is not the favourite toy anymore, what is left for him to do?

And I have to admit, my mind is doing that exact same shift.  I made a technology shift after five years, and now, after another five... I find myself looking to aquire a copy of "The results-driven manager".

Thankyou for making so painfully obvious what we as programmers feel once we have been working for a little while.... Can't we dream just a little bit?

You can only say "I told you so", so many times before you try to take the helm, and hope that the next level of management up listens a little more.

I think, I've even given up on that illusion as now; I have this crazy dream that if I were to ever run a company... Managers will be paid based on a percentage of the wages of the people they manage - you want to improve your wage, you improve the skills and worth of the people under you.  Tell them, that as a manager, you are not expected to know all the answers (one of the problems of having ex IT people in the job), but you are expected to listen to the opinions of the expert (and hopefully smarter than you), people that you hired.... and above all else - keep them happy.

If anyone already has such an environment feel free to drop me a line - I love being a programmer - untangling an SQL performance diagram, that's simple - untagling the web of management approval... now that is hard.

Does anyone have a story of hope for the dedicated programmer?  I still want to dream!

Andrew Watson

I think the previous posters have summarized the argument as to why programmers become team leaders and then managers; the technology shifts, and as the technology shifts, it becomes harder to stay abreast of the skills needed to be a good programmer.  That's not a bad argument, but it assumes that a good programmer is little more than a wizard with a fresh book of spells; the older you get, the harder it is to get more spells, and so you quickly fall out of favor with the lords of the realm.  I don't think that's the whole picture.

I agree that having good coding skills in the language of the day IS important, and that's an investment that both the employee and the employer have to make, but the essence of a good programmer lies not in their "code-fu", but in their ability to design and build applications that meet the needs of their clients (whether in-house or external).  That's a subtle difference, but an important one.

Granted, many lords of the realm are looking for the hottest wizard; they hear a buzzword, and think that by throwing the right spell at a business problem, they will be victorious.  But, does upper level management really care if an app is written in HTML or PHP if it solves the problem?  Programmers care, which is why we grouse about having to support the app that some guy who left 10 years ago wrote in a DOS editor overnight, but management doesn't.   Management just wants to solve the problem in the most cost-effiecient method.

I realize I'm rambling a bit, so let me stay focused: I think businesses benefit when programmers worry less about the coding skills they have, and focus instead on finding solutions to the problem.  I think businesses should find ways to encourage good programmers (those who put solutions first and coding skills second) to mentor other programmers, but ultimately, they need to invest in the programmer to learn new skills, become more invested in the company, and avoid the greasy pole.  Skills may get you the job, but solutions let you keep it.

I agree completely. As one of these oldies (well, not in my eyes!) who has just past 40, in all the companies I have worked in, only one has had a career structure where you could stay in the development stream, and head towards lead architect, or take he management path. Every singe other one has pushed developers into the politics strewn field of management (yippee! :( )

Until the profession seriously takes on that not all developers actually WANT to become a manager (usually via team lead, project manager etc) then alas people will continue to pretend that they have those ambitions when at interview.

Forty, Spud? Pshaw. Hardly out of college.  I went for an interview a while back and sat opposite a manager who had a rehearsed set of questions. He looked at me and asked 'How would you like to see your career develop in the next five years'. We stared at each other goggle-eyed before bursting out laughing. I then admitted that staying alive and employed were at the top of the list.

You have to look at the upside of all this.  If your boss isn't very technical, then you don't have to be very good; you only have to be good enough to be more technical than him.

In my 25 years of work experience I've found that many mangement positions are way overrated.  On a relative scale, many managers have responsibilities that are not proprotionate to their pay and are thus compensated at a rate that is effectively lower than most of their suboordinates.  I started my career as a first line manager for a fortune 500 company and made a couple of hops over 6 years before realizing that being a manager wasn't really so great after all.  I can't count the number of bright engineers that I've seen flame out once they became managers.  After 6 years in management, I bailed and went back to school , picked up a Computer Science degree, and have never looked back.

Although I make about $15K less than my boss (a manager), I'm only responsible for my own actions while he is ultimately responsible for the actions of over 40 individuals.  My boss has to regularly participate in a number high level politically charged meetings while I do not.  I'm paid overtime or comp time if I work over 40 ours in a week, but my boss regualrly works in excess of 50 hours per week and receives neither.  My boss has to interact with the media, but I do not.  My shorter work allows me to spend more quality time with my family and pursuing outside interests while my boss doesn't have that luxury.  To say that I'm happier than a pig in slop would be a severe understatement.

I've also never bought into to the narrow minded corporate philosphy that an employee is continuously moving up or they're moving out the door.

Although I never say never, at this point I have no career aspirations to return to a management position.  In fact, if my current employer was to promote me to a manager, I'd probably quit.

If you want to ruin a good engineer, then promote him/her into management.

 

Best editorial title. Ever.

From my experience, I find that the manager is a key part of the success or failure IT projects.  The key issue I have seen in failure has been one of business process: does the application fit the true business tasks, and are users doing their jobs with the new system effectively?  I think codegumbo and I are talking around similar points here.  

For success in a big project, someone has to be accountable for the application getting put into service.  This may come down to someone with the authority to determine what the business model is, or to issue a directive to recalcitrant users.  This is by nature a political task, but if you don't have it, why continue developing the solution you are working on?  The wowie-zowie technical back end won't matter if it doesn't solve the problem or get used successfully.

Developers don't have to move into management, but they do need to focus on improving the success of projects.  Knowing the development costs and the stakes to an organization (of maybe a multiyear ERP implementation) of a change in business process is one good reason for a developer to become a manager: to get the political buy-in for big changes, and articulate at all levels the goals.  If you don't feel up to business process reingineering you still need to focus on successful solutions, such as gaining skills in requirements engineering in the discovery phase and usability in the implementation.  

I too have no desire at all to become a manager; the thought of management of other people's time and resources frankly scares me. It is all I can do to manage my own. However I want to say something. Many people here (particularly Keith just above me) have said, in effect, that the fun of programming needs to be sacrificed to the needs of the organization, to lesser or greater extent, which to me sounds too much like knuckling down to the whims of a pointy-haired boss.  The compensation of being a programmer isn't all money -- this obvious truism is the reason why anybody ever starts as a programmer. And taking away the fun of programming is pretty much taking away the reason to program.  Project failure has many causes, and one of them is disinterested people on the job. And if too much of my job is uninteresting, I'm likely to change jobs.

Tony:
The churn in our industry comes not from business, developers or managers. The churn comes from the makers of the published languages. They are driven by market economics.
Microsoft destroyed the old foxpro language, created and new one and a different market. They made money on the old foxpro, the new foxpro and from the folks that switched to VB 4-6. When MS destroyed the old visual basic, all those programmers, the businesses that supported them and the user communities almost completely disappeared. Today there are still VB 6 programs being created but there is an entirely new market for vb.not, C# and the incredibly complex languages associated with .NOT aka .NET. Microsoft makes money from the continuing VB 6/ASP/SQL 2000 folks, the VB.NOT/ASPX/2000,2005 crowd and those coming along now.

The programmer is incredibly burdened. He must learn an entirely new language/object model every year to remain current. AND maintain the knowledge of the old languages to sustain the projects of the past. Programmers burn-out. They long for the easy life of the manager who doesn't have to keep-up with all this churn by the language makers.

Someone should have told them before they signed on that MS, Sun and the hacker community were going to create new languages every 6 months or so and they were going to have to become experts at those languages. I wonder how many would have joined the field if they knew the mess they were getting into.

As always, I have refrained from reading the other musings, in order to remain chaste.  Why do "seven out of eight IT projects fail" is the real question.  So here we go; and rather longer than usual.

IT, unlike real engineering or medicine or lawyering etc., has no concept (outside of the few guru status published folk as CELKO or Date) of eminince grise in the workplace.  It did, to some degree, back when there was still IBM and the Seven Dwarves:  there was still a playing field, albeit not level.  But back in those days, each had an interest in building something that was really better, and by definition different, from what the rest had to offer.  Burroughs was the last survivor; Multics may have been the best example of what technical competition can create.  In those days, being a manager of technical staff meant that one had to know the tech bits better than the staff; the manager really could do any of his (and yes, almost always he) staff's work better.  A manager was closer to being a field promoted military officer, schooled in warfare as a soldier then tactics as a junior officer and finally strategy as he got more experience in battle, who gave orders that had technical meaning.  A mentor as well; a Master Builder.  Not just one who points at a Gantt chart demanding that Stage 13 be done by the end of the week.

But then, something happened.  Since I abide on the West Side of the Pond, and New England specifically, we call it The B School.  The rest of you call it the Harvard School of Business (and it's in Boston, not Cambridge; yours or ours).  The B School started out as a Finishing School of undereducated managers of a certain age in need of a graduate degree.  Said managers were from Sales or Marketing, never the dirty hands side of the business.  I haven't been keeping track of X, but one couldn't go from a Baccalaureate to the B School; one needed a minimum of X years of work experience.  My sense is that X has diminished over the years.  The B School started the evil trend in thinking:  management is a separable skill, unrelated to even antithetical to, the product being made.  Since The B School trained Sales folk, people skills and persuasion were the order of the day.  So was born the Professional Manager.  A Professional Manager could manage any activity.  

And so too was born the decline of American (and any other society which drank the Kool Aid) commerce.  (Aside:  Jack Welch was nearly universally acclaimed the world's greatest professional manager by turning GE into a profit machine.  A few questioned this belief, pointing out that he had done so by stripping away manufacturing and substituting financial services.  Well, what do you know?  GE doesn't look so good now.)  So, one proposition shot down:  management is not a separable skill.  A manager really does need to know the field.  We have world wide collapse of the financial system because the Professional Managers didn't have a clue what was going on and didn't care; the Gantt charts were on schedule.

The side effect of this transition was the demise of technical management in many areas of commerce.  One sees less of this in medicine and law; I expect that this is due to the effect of being sued if one is grossly incompetent.  In IT, no one dies (usually), so no one gets sued (usually).  Soon enough, IT succumbed to Professional Management.  Does anyone remember that the Apollo moon missions ran on computers (on board) less powerful than the first PC?  Or so the story goes.  It may not be exact, but close.  Built before Professional Management.

With the dominance of the Intel chip, windoze, *nix; homogenization across the board means that technical competence is viewed as not important or unique, all IT folks are equivalent, human widgets.  This homogenization is seen in the lemming rush to the web, xml, java and the "frameworks" which have grown up from them.  What Hani calls "open sores software".  IT has become dumbed down to a perilous degree.  The Professional Managers read about Object Oriented programming, and EJB, and xml, and so on.  Since they now have the authority with little or no technical competence, they make the decisions; or what is almost as common, get flummoxed by some KiddieKoder who just had to do EJB1.  It is lemming development.   Everybody uses FooBar, so we too must use FooBar to remain competitive.  The lunacy of being competitive by doing the same thing, by imitating the other lemmings, is problematic.

There is also, and it may be a greater pressure than the transition to Professional Managers, a generational battle.  In days of yore, when there were Master Builders, the youngsters learned from the Masters.  It was the Master Builders who had the experience to know when to change a paradigm; when and why the old one didn't work, and what the new paradigm should be.  And so it went for centuries.  Those who built the first computers are largely pushing up daisies, but in the software world (measured from the advent of COBOL, which persists like herpes) the baby boomlet (I bet you didn't know there was one, did you?) put pressure on the situation.  The boomers wouldn't die off fast enough for the boomlet generation to progress, so they went and redefined the profession; mostly re-inventing that which had been already replaced.  It wasn't the Masters, but the apprentices who changed the paradigms.  I have in mind:  xml is just IMS but not so good and OO programming implemented like COBOL but in lower case.  Since this is a relational database forum, need I remind the group assembled that the younger generation rarely knows who Codd, Stonebraker, or Date are.  

With the hegemony of the OO frameworks, real thought about system design has disappeared.  Rather than standing on the shoulders of giants who came before, we fill anew pits of quicksand from which they delivered us.  It is very much as the world was in 1969:  the code (now java, C#; then COBOL) is "smart" while the data is "dumb" (now persisted in a "database" eschewing the ACID services of the "database"; then written to VSAM).  The lessons of Codd and the rest have been not just ignored but denied, replaced by API contracts and mountains more of code.  Rather than robust systems of databases, the youngsters seek to write ever more code.  Ever more code means ever more failure.  I have heard such folk tell clients "we prefer to manage the data in our code".  They do not understand that the Web (2.0 or otherwise) is just a bunch of 3270's attached with really long slow wires.

Having killed off the technical manager, replacing with Professional Managers, it is natural that 7/8 fail.  It would be shocking otherwise.  One of my favourite analogies:  I have a neighbour who is really good at cutting up chickens for dinner, so much so that he is seeking work as a head of  neurosurgery.  He knows he is well qualified.  It is just cutting, after all; I can certainly manage that.

So, if one is Middle Class, with a Spouse, a detached Estate, dental work for little Charlie and Annie, a Volvo, and two weeks in Brighton (that's where one goes in the Summer, yes?) what is one to do?  Follow the money, of course.  The fact that Middle Managers are little more than timekeepers, well that's somebody else's problem.  The need for ever more gelt leads to the greatest evil:  since the Professional Managers get to define what it means to be a manager, really good technical staff risk getting tossed out of the manager's club unless they behave as Professional Managers; they must be Borg.  And 7/8 projects fail because no one in Management will acknowledge that Professional Management is the problem, even as Professional Managers have reaped the whirlwind for all of us.

So, how does one get along?  There are a couple ways, neither easy.  One holds on long enough, and publicly enough, to achieve CELKO status.  I assume that he lives rather high on the hog, but who knows.  Or take the route of Phil Factor (I'm clearly dreaming here, I know not the wo/man), itinerant developer; a Candide of computers, the kid's teeth be damned.

I think many people that are successful developers feel that they must move into management because that is the next step in the career ladder.  I myself fell into the trap.  After a career change into software development, I spent 8 years doing development at a couple places and then took the leap (or is it fall?) into management.  According to my boss, I was doing a great job.  However I didn't feel as good about myself because it was hard to measure my contribution in any tangible sense.  I actually missed being the programming geek that people came to for solutions.  So, after 2.5 years, I asked for (and received) a demotion to a part-time developer while I grew my consulting business on the side.  Six months later, I quit and went solo full-time and haven't looked back.

The crux of the problem is people feel like they must move into management to be successful (or for the $), which often times puts people into jobs that they don't like or won't perform well.  One solution to this is to create two tracks of upper-level staff - one for managers and the other for technical experts.  They should be compensated similarly and the technical experts would not have supervisory duties, but would serve as mentors and "go to" people for projects/problems that are important/difficult/etc.  This allows people to stay where they are comfortable (and good) and will generally help the company more than if they moved to management.  I worked at a company that implemented this two track method and I thought it was a great idea.  

Being a software manager myself, I have perhaps a slightly different perspective on this.  I've managed literally hundreds of developers over the years.  In terms of talent, some of them were rock stars, some of them truly sucked.   Most were somewhere in between.

It's been my experience that great developers ARE managers, whether or not they actually think of themselves as such.  To explain why, I would like to share with you what I call the "Wheelbarrow-Train Track" performance scale for developers.

A friend of mine who manages hourly employees once told me that his workers are "like wheelbarrows:  they'll work plenty hard for you until you take your hand off the handles, at which time they'll go about 12 inches and come to a stop".

A manager of mine once marveled at one of our best developers.  He said, "that guy is like  a train that lays its own track in front of itself".  

And so, over the years I've come to think of developers on this scale, whether they need to be micromanaged at the task level, or whether you just wind them up and they crank out value.  My experience as a software manager is that there are developers who are like wheelbarrows, and developers who are like trains that lay their own track.  There are way more of the former than the latter.

So, for my mind, if you fall into the latter category -- proactively identifying issues, helping to make your surrounding team members more productive, growing and refining the list of project activities, etc. -- you already ARE a manager, whether or not your title reflects it.

Finally, I don't think projects fail because the developers are inexperienced, or because the managers are idiots.  Well, okay, some of them DO fail because of that.  My experience is that projects fail because they either have a poorly defined mission, or a poorly defined set of success criteria, or a dubious value proposition.  Projects fail not because they lacked developers with sufficient knowledge or SQL or C# or UML, or because they lacked managers with sufficient MS Project skills.  They fail because there's no one on the team who can state in one single sentence what the thing is supposed to do, and how they'll know if they've achieved their goal.

Could this pushing out of experienced people be the answer to why the industry is always considered to be young and why we are constantly repeating past mistakes?

It is interesting to read comments where people see new things as being re-inventions of older technologies. This is something that I have noticed myself. When new technologies or approaches are celebrated in tech media are they just commenting on some wave of interest generated by the newest batch of developers who are discovering them for the first time?

Constantly refining and improving can be good but we should not throw away lessons learnt. Maybe we should lok at having more of an apprentice type environment where new developers can learn from experienced.

It is not always easy to justify to management the cost of experienced developers. Maybe as projects are filled with more cheaper recent graduates then experienced developers people need to move into management?

When I was consulting I worked at a company where most of the development team had been working together for nearly 20 years. There was no pressure to move into management. The skills of developers were valued. They had a really mature process with lots of team input and feedback with constant growth and improvement.

Develoeprs should look for a work place for the right fit for them. They should not be pressured into management.

PingBack from http://msabuwala.wordpress.com/2009/03/06/why-do-programmers-wish-to-become-managers/

The blame here lies on both sides, but most of all it lies with us, as developers.  Software and IT are relatively new in the business game and have been bolted on to business as a "necessary evil".  

Throughout this time we have failed to make good enough arguments to explain our craft, yes it's a craft.  This has lead to a lot of business people that think that the idea and the business are what matter, and the software can be developed by anyone later.  A lot of developers are focused purely on technology and have no business skills.  Some even believe that the business doesn't matter, just the technology.  The reality is that both matter equally and must be integrated.  Business decisions made without considering the development ramifications are doomed to failure and technology decisions without considering the business are equal folly.  This is why most software development projects fail.

Too many developers spend their days implementing ideas they don't understand, and likewise too many managers think the idea is all that matters.  Developers need to wake up and understand that management and business skills are an important part of their craft.  The best software managers are still ACTIVE developers and the best developers understand the business.  

We need to educate the business, and educate ourselves on the business.  In doing so, we can change the culture so that it's not necessary that the only career path is into management which requires us to give up being a developer.  Unfortunately the majority of us are going to have to learn some skills from the business camp and change perceptions and status quo of the businesses that develop software.

I've already given a response, though one that was a little on the tongue-in-cheek side.  I'll try again.

It seems to me that who gets promoted, or who should get promoted (separate questions, of course), depends on what kind of a business you happen to be in.  There are firms that exist to produce software systems.  There are firms that exist to maintain software systems.  There are firms that work for a software seller, and firms that work industries outside of software development, for which an IT shop is there mainly to provide decision support and to guard the enterprise data.  There are firms that work in the private sector, and there is the public sector (not quite a firm, is it?), and also firms that work for that strange netherworld of contractors who do the actual work of the public sector.

Any way you categorize it, a shop has different needs depending on the firm's mission.  Someone who manages a shop in an entrepreneurial software company might not succeed in a shop where he is only a shepherd of software developers within an outfit whose main business is insurance.  And vice versa.  The CEO of a company that sells software for a living might absolutely require all of his managers to be technically savvy; such a company might place a high value on technical know-how.  The CEO of a bank might be content to hire a manager who understands the business of the company and manages the IT shop based on that knowledge; such a company might place a greater premium on dependability and ability to communicate.

We can argue in the abstract about what types of people ought to be promoted into management -- and usually our arguments will boil down to touting our pet sets of virtues -- but there is room for complaining, either way it goes.  Promote a good techie into management, and we can complain that it's a waste of good talent and there should have been a technical career path.  Hire a non-techie and make him the commissar of programmers, and you may have the opposite problem of having someone in charge who may not have the background to understand the salient issues.  Worse, he may not understand that he doesn't understand.

But let's stipulate that sometimes a talented programmer is enticed into management for no better reason than he wants more money and that's the most convenient way to get it.  Granted, many programmers are ill-equipped to deal with people, but there is no reason to suspect they are any worse at it than many who aren't technical.  Character, after all, is the defining virtue of a manager, and (in my book) the only non-negotiable item -- and I don't think it is any more scarce among programmers than among others.  I don't see losing a good programmer to management so much as a loss to the craft, as an opportunity to inject sanity into the meeting rooms in the higher echelons of the firm.  I have worked for all sorts of organizations, and the only pattern that I see that truly alarms me is when there is a powerful high-level manager who does not know anything about software except his preferred schedule -- what he wants done and when he wants to have it.  Some of them are quite immune to any evidence that what they want cannot be done in time, or done well enough.

If you want to retain gifted programmers, it's simple:  you have to pay them what they're worth.  Big corporations don't do that because they want to believe that even low-level managers are worth more than technicians (naturally, since the corporations are run by managers), and they refuse to pay a programmer more than his boss.  Government doesn't do that because it subscribes to a rigid, hierarchical job classification rubric that is an ingrained part of the culture (which is why they need to have so much of the work contracted out).

Maybe the solution, if there is one, would be to hire contracting firms to do all the IT work, so the client companies don't have to know how much the hyperactive youngster with four nose rings and an IQ of 165 is really being paid.  But that's not a solution either, just a trade-off, as it's hard to instill loyalty in a hired gun.

So, not having a real solution that jumps out at us, we simply await the market to decide the best trade-off by trial and error, depending on applicable set of circumstances.

There’s a decayed sense of unhippiness about developers still coding after 49 1/2, because technology is left to the 20-something, caffeine-laden code jock.  Management is the retirement heaven of former rock star coders who’s thrown in the towel to escape father-technology (the counterpart of father-time for you sports enthusiast).  Most of us will eventually succumb to the rigors of catching up or keeping pace with technology.  Those who stay, build fortresses of legacy code to keep them indispensable in their current role while others promote themselves to failure by taking on management projects and tasks.  How different can managing servers and codes be with managing people? (Subtle hint of sarcasm)

Developers stop being developers, not because they had a sudden epiphany that management is the enlightened path.  Keeping up with technology and the allure of riches and false-sense of power is hard to ignore when comes knocking at your door.  Companies should throw more money to keep excellent developers in their field, how many NFL or NBA teams have given their franchise player more money to become a coach? None, because they want to keep their star players playing.

Management is a calling, let those who are called to be managers manage and keep the rock star coders coding by giving incentives to keep on playing!

I've worn many hats in my professional life span - oddly moving from sales, to management and across to developer / DBA / data warehouse dude.

I think you're spot on with the tendency, but it is something that goes on in almost any discipline and since I'm older, and more cynical, I think it has to do with some bias in companies as to the value of an employee.

For instance, when I was younger and in sales, it was easy to know who was going to be 'bumped' upstairs into management.  The sales people who were just starting to really grow their businesses (and hence, their commissions).  Where I worked it was common knowledge that the senior executives were quite distressed and put out to find that mere 'sales people' were earning as much or more than they were - hence commission caps were put in place and people started being 'elevated' to management.  However, just as with developer skills, good selling skills do not translate automatically into good sales management skills.

Moving back to development - how do you justify the 50-something programmer?
The mentality is that they can hardly 'keep pace' with the young guns coming out of school, freshly minted on all the newest (and therefore greatest) technology, right?
This shows a biased set of thinking that: a) ignores the incredible value of experience; b) assumes 'older' means more expensive and wasteful given the (incorrect, but nevertheless widely held view) that all programmers are pretty much interchangeable.

It just boggles the mind that companies large and small keep doing this, even though it doesn't really pan out... as you attest to with the '200 billion' failure statistic.

Yes there is hope. I work for a company and manager who have provided a "technical" career path, without pushing me into a managerial role. I initially did some "managing up" in order to help them understand that if they really valued my skills and contributions to the company, they would see that providing the programmers an opportunity to do what they do best over a long and successful career and acknowledge those skills with promotions and raises, that would contribute to company success.  I am happy to say that for almost 9 years now, the company has done that ,and has seen continued and sustained grow.  

As a department we are always talking about integrity, communications, and teamwork.  Our manager relys on the technical skills of the programmers to drive the decision making and trusts senior developers and analysts to do their jobs.

Using the metaphor, his job is to climb the "greasy pole" and keep the wheels greased so the train keeps moving.  It is our job to lay the track and keep the engine running.

Lots of great comments and insights, here.  I particularly liked BuggyFunBunny's.  The part about how data and databases are viewed really struck a nerve with me because I've just run full-tilt into that "the app is all and the data is a mere inconvenience" attitude where I work.  Then they wonder why performance sucks.  Hmph!!!

Part of the career-path issue here is that all too often people are promoted to their level of incompetence.  After all, if someone is good a X they will be good at managing X, right?  Double Hmph!!!

kperkins, where do you work and are you hiring?

DatabaseGeek, thanks for the humourous summary.  8-)

It is really nice and good to be a expert programmer for whole of the service, but i found a problem for being as a programmer after got more experience because the superior people like team lead, section head etc., keep putting burdon on programmers.If those people realise and not put any burdon on programmer iwould prefer to be as a programmer all of my service time

any how the idea is really good

What a bunch of baloney.

I'm 48. I started programming in 1974. I've managed teams of up to 120 developers and budgets of $20 million or more. I've alternated management with hands-on programming. Right now I am a hands-on programmer building systems for a small hedge fund. I've found no comp difference during my career between being a manager and being a developer.

You have to manage your career. Don't ask or expect others to do it for you. You need to be more innovative and creative than the next guy. Use modern management techniques and technology (duh) to delegate and track deliverables. And if you want to be hands-on later in life, but get management-style comp, it helps to work at small companies.

p.s. we have been unable to fill other senior positions because, not surprisingly, 26 year olds with 5 years of experience are in fact not very experienced. I am in one of the largest urban areas in the US and can't find developers senior enough.

Experience is everything. I'd be amazed if anyone under 35 would have the skill set and maturity to succeed in the hands-on development roles we have open.