Code for life

All programmers inevitably face the decision; to either stay in their hands-on development role, or to switch into a hands-off role.

I'll cut to the chase. I think the reason a lot of corporate software sucks is because most corporations push their most talented technical people into hands-off roles. The advancement opportunities dry up for a hands-on developer around the time they hit the really senior developer role. The title may be different depending on the company, but it's the last rung on the ladder before you move to the high-walled corner cubicle (management) or ivory tower (architecture). But you'll almost never see a hands-on developer with VP at the end or their title unless your company name starts with Face and ends with book. So, what's the deal? Why don't banks, insurance companies, and so forth include hands-on developers in their upper ranks?

It's because your value to a company as a full-time employee has less to do with your technical chops than your business domain expertise. There's a big difference between working in a brand new business domain (internet search, social networking) and working within a well established one (banking, government, health care). It's the reason why developers are outsourced but (for the most part) business analysts are not.

Let's say you work at a bank. You write code. Unfortunately, banks don't consider themselves software product companies, even though most banks live and die based on the quality of their software. So in order to be viewed as a valuable member of the team and a candidate for that huge corner office, you need to know an awful lot about banking. And if you know that much about banking, chances are the powers that be don't want you writing Java, they want you working your mathematical magic and/or talking at a lot of meetings. There's nothing wrong with going to meetings all day if that's your thing, but there's nothing worse than watching someone get railroaded into that position. In corporate-ville, talented developers are believed to grow on trees; the Tata tree, for instance. Developers are viewed as pluggable, modular components. They fit in a hierarchy chart nicely, sometimes listed by their name, other times listed by their title: "Developer 1", "Developer 2", and so forth.

So, what's the hardcore lifelong hands-on code monkey to do?

• Learn your business domain inside and out. Think PMP, CMMI, CFA, etc. There's no reason why developers shouldn't at least know what the heck these things are, depending on the business domain obviously.
• Quit your 9 to 5 and consult or contract. Work your ass off. Always deliver more than what's expected. Guard your reputation like your life depends on it. And have lots of fun in the process.
• Understand your place on the corporate hierarchy and use it to your advantage. How many people get to switch from one interesting job to another, make great money, never have to feign loyalty to any single entity, and make new contacts each time? Not many!
• Keep your technical skills razor sharp and always up to date. Teach other people what you know. Network constantly.

There are a lot of options for code monkeys who keep an open mind about their career: technical team leadership, hands-on architecture, business systems analysis, and the list goes on. Sure, BSA work isn't exactly writing code, but working as a BSA for three or six months would give any developer a whole new set of tools for their toolbox.

Just don't let yourself get railroaded into a career path that doesn't work for you, because there's nothing worse than watching an amazing developer become a horrible manager. Take control of your career, otherwise other people will take control of it for you. And even if other people don't always acknowledge it, realize that by staying in the trenches you're helping to make corporate software suck a whole lot less.