I've been thinking a bit - especially after talking to Dan North over a coffee last week - about titles in software development, and I'm fast coming to the conclusion that titles are for other people - and I mean that in both ways.
I mean that in that I am not overly interested in a "title" any more. It's redundant, especially as what I do can't be summed up in half a line on a business card.
But mostly because a title, to any software developer I know, is more use to those who they work with - not so much to themselves. Mostly it's useful to HR, so they can say "developers get $Z, senior people get $X, but architects get $Y".
And to get it out of the way, and how this all came about: my current "title" - what it says on my official business card - is Architect, the most debated and either loved or hated title of them all. But not one I feel fits what I do.
In traditional building - and really, what we do IS building, or at least creation - an architect draws up the plans for a building, making sure it's going to be totally safe and what the customer wanted, and then pass it off to the builders to make it. Sure, changes can be made when the builder is doing their thing, but generally, that's a bad thing(tm).
Really, that's not a lot like most of the software architects I've worked with - or with what I've done for the past 3 or 4 years. Software architects who throw things over the wall - which is really what building architects do - are looked down on as "working from an ivory tower" (and rightly so). More than that, throwing anything over any wall - a software design, testing, any spec - just doesn't work in an agile team, which is the direction software creation is (and rightly should be) going. Thankfully, most of the people and places I've worked the past 5 years have seen that. Phew.
But given that labels are kinda "the thing" in the business world, what would you describe me as? Here's a short list of what I've done:
-
build and designed software from scratch and adapted existing systems;
-
integrated with other systems, both 3rd party and in house;
-
mentored other developers;
-
presented to clients and large groups of developers;
-
talked to pre-sales customers and convinced them (to some degree) to part with six figure or more sums;
-
debugged production code on production systems;
-
supported large clients with serious problems and helped run a 4-time-zone distributed team.....
... you get the idea. Pigeon holing isn't easy. Most of the "very senior" people I've worked with have a list like this. It comes with 15 years in the industry. A large number of them worked on Top Gear. (* Craig, if you are reading this - no, I'm not looking for another job. Yet :) )
I prefer to think of myself as a grey haired developer, and I'm quite aware that those words are stolen from my old boss and friend, Phil "Orbiz" Verstraaten, who played the grey hair card a few times while I was there.
Another way to think of it is like Eric Schmidt at Google: Adult Supervision for the other, less experienced developers. Someone who can go into a client meeting and talk to both sides - developers and business - in their own language, and make sure no one gets screwed or throws their toys. That's pretty much what I've done for the last 3-4 years.
The problem, as most development managers, and people in my position, know, is this: What do you do with someone who is no longer a senior developer? They are worth more to the company than a normal senior developers salary, and you don't want to let them go under any circumstance. They don't sit down all day cutting code (tho sometimes they do) and mostly they are either making sure everyone else is running at 110%, or running interference so the crap never even gets to the rest of the team. They are as much use at the very start of a project - typical architect time - as at the end.
A good manager will know they are going to be awful at managing people (or worse, get bored and leave), so moving them into a development manager position isn't a good solution either.
In most places, you do one of three things: you either call them a team leader or development manager, tho make sure there is someone else there to handle the "nasty" people side. You invent a "more senior" developer position, or you call them an architect.
There is a fourth option: there are a few companies - Microsoft and Sun, for example - who do have a formal position above senior: usually distinguished engineer. I like the idea, tho I don't consider myself an engineer, so maybe distinguished developer. I'm not sure I'm in the same class as Anders Hejlsberg either, who holds that title at Microsoft. But it's close enough.
Plus, everyone knows that "distinguished gentlemen" have grey/silver hair. Hence grey haired developer. Now thats something I can put on my business card.
(again, for those who know me really well, if/when I have enough hair to see, it's getting greyer, quickly, so it's quite apt.)
How does this sit with others in the GHD camp? The unwilling architects? I'm not saying you get to GHD "level" just by having a few grey hairs, because I've worked with some awful older developers. It's more a case of "I've been around the block, and I know which battles to fight and which ones to not bother with".
Thoughts?
Image stolen from Project Cartoon.
