I Just Want To Be a Programmer. But Can I?

I like programming, and I'd prefer that the majority of my day consist of it.  At this point, I have no interest in being a manager.  Things like attending countless meetings, writing little to no code, and worrying about budgets just don't appeal to me.  No offense to managers, but I like doing "real work".  Yet I do often worry about future opportunities if I eschew the management career path.  Will it be financially viable and intellectually stimulating enough for me to remain a programmer for the rest of my career?

Page 107 of DeMarco's and Lister's Peopleware: Productive Projects and Teams does a good job describing part of my fear.  Although they're mentioning companies with higher rates of turnover, I think it's the general attitude of many companies.

"If people only stick around a year or two, the only way to conserve the best people is to promote them quickly.  That means near beginners being promoted into first-level management positions.  They may only have five years of experience and perhaps less than two years with the company.

There is something very disconcerting about these numbers.  A person with a work life of, say, forty years will spend five years working and thirty-five managing.  That implies an exceedingly tall, narrow hierarchy.  Fifteen percent of the staff is doing work, with eighty-five percent managing."

There's several things wrong with this.  For one, it means that there's a lot of managers with little programming experience - and that experience could have been from quite a long time ago.  It also means more managers than programmers, leading to what I call the Eiffel Tower corporate hierarchy.  But in regards to this post, it also means that at a lot of companies, the only career path is management.  The most talented and promising become managers.  But what about people who don't want to become managers and just want to continue excelling at what they currently do?  What prospects do they have?

Like I said, right now I just want to be a programmer.  But that doesn't mean that I want to do the same thing for the rest of my life.  Granted, I need to continue to make enough to live comfortably (and that amount unfortunately continues to increase), but more importantly, I want a job that continually challenges me.  In terms of programming, that means a job that allows me to use new technology, tackle complex problems, and assume responsibility for larger and larger features in terms of scope.  But on a team with several talented programmers, how do you provide career growth?  You can only have a handful of architects and lead developers, so simply promoting everyone doesn't work.  So how do you keep a team together while still giving everyone on the team a chance to grow?  Is this possible, or do programmers have to move onto other jobs in order to continue to grow and face new challenges?  Or do you reach a point where you just accept that you're at a good company, you get to write code in a somewhat enjoyable fashion, and you leave it at that?

Abhorring the Rewrite

Sam Newman has a good article sarcastically depicting why rewriting an application from scratch is rarely a good idea.  I share the same sentiment.  In fact, I think I'd go so far to say that I would strongly consider leaving a job before participating in a rewrite of an application.

Why?  Well for one, rewriting seems like a lot of time and effort to deliver a new product that simply meets the existing functionality of the old one.  And it sidesteps the real issue at hand: that the team doesn't know how to care for and improve code as it ages.

The code is difficult to work with because, for some reason or another, it wasn't continuously improved over the life of the application.  This might have been due to time constraints, not knowing how to refactor, a lack of discipline to do refactoring, or just a general lack of care for the product.  Rewriting the application from scratch doesn't address any of these issues, so you'll eventually have another codebase that's difficult to maintain.  Instead, programmers need to commit to the routine cleaning and improvement of the codebase, and management needs to support the programmers' efforts to do so.

In some ways, dealing with an aging, unwieldy codebase is like getting a knot out of a piece of rope.  You can cut the knot like Alexander and just do a rewrite, but what happens when you get another knot, which you assuredly will?  If you keep cutting, you'll eventually run out of rope.  On the other hand, you can gradually pick away at the knot, loosening small bits at a time until larger parts of  it start coming undone.  And eventually you'll have the knot removed - along with the experience and satisfaction of resolving a difficult problem.