Two recent articles (Are You Too Old to Code and Teach Yourself Programming in Ten Years) made me realize that the Peter Principle is alive and well and living in New York, um, the Software Industry. The software industry (Information Technology in general) is unique in that it's got no real barrier to entry, especially for such an important infrastructure field. (I still don't have a college degree, even after 15 years in the industry) No formal education necessary, many of the tools are free (Java, .NET Framework SDK, Perl, etc...) so the only cost is a computer, situation where demand outstrips supply (or there was) So you've got a field where it's easy to start young, and yet still be viable for a long time to come. (Viable here meaning able to code, I'm not referring to marketability)
That lack of barrier to entry, I think, is what skews the whole industry for veterans. The ability for a shop to hire a kid off the street for a low salary makes it difficult to want to spend more, especially when it's difficult to understand the nature and complexity of IT. ("If I can pay this guy $XXX, why should I pay you $YYY?") Add to that the upward nature of corporate structure, and you've got a recipe for disaster.
I beleive in the Peter Principle. Some people are coders, some people are developers, some people are architects, some people are team leads, some people are managers, etc... (And that's not to imply that manager is the next step after architect) (Me, I beleive I'm an architect.) In fact, I beleive that IT demonstrates the Peter Principle better than the examples from the original work, considering the complex layers that make up a good software shop. (Compounded with the fact that many organizations don't fully understand the nature of their own IT department) A good developer/architect is not likely going to be a good manager or even team leader. Sure, he may understand the nature of the work his underlings do, and have a good grasp on it, but that doesn't mean he's got the temperment to manage them, and deal with all the paperwork necessary. Nor should they. Let the architects design, let the managers manage, put the two of them in a room together to make sure the project is staying on track both design and time/resource-wise and you've got a recipe for success.But make that architect manage, and the project may be doomed from the outset. (Conversely, put in a manager with no technical skills, and it might be just as doomed) I've even worked with a "Coder" who sucked at design work. Put him on a well-defined task, and let him go, and you'd have fast, fast code. But don't let him near the design, or you'd be in trouble. (Or ask him to test, or debug... but that's another story.)
So where does that leave us? We, as an industry, need to address the attitudes of the corporate mindset.
- Don't take a promotion if it's going to put you out of what you love to do. Ask for a raise instead, especially if it's just a reward they are looking to give you.
- Find someone else more suited for the management posistion. I've help people get promoted "over" me several times.
- Demonstrate your value of staying as a developer as opposed to being management. The more time you can spend coding, the better your value, right?
- If age discrimination is an issue, demonstrate that it's not. Show that you can work in new technologies, even if you don't do it full time. There's nothing worse than working with a programmer who refuses to learn and grow. (Which leads to my next point)
- Continuing education is a must. My wife works as a counselor/therapist, who already has a master's degree, and she has to demonstrate 36 hours of continuing education a year. Why should we, whose programs and networks provide the infrastructure for everything, get by with anything less. Make learning something new a goal, even if it's just something new within your chosen ideology. (C#, Java, C/C++, whatever)
- Read. If you don't understand something, pick up a book, and read it through. I learned XML and Unit Testing just because I wanted to learn what all the fuss was about.
- Do. As mentioned in the article about programming above, it's one of the best ways to learn. *And* to demonstrate your talents. If you can't write something you want at work, do it in your off-time.
The real developers in the crowd probably already do this, but it's still bears thinking about.The only way to change the mindset about IT is to demonstrate what's wrong about it, and what could be better.
And that's something worth developing.