From the previous post, Alex raised some good points:
I’ve always kept GHD and distinguished developer separate in my mind, I see GHD as a ruthless pragmatist, with a rich set of client interaction/translation skills and a wealth of real world experience.
A distinguished developer to me often represents someone with raw intellectual horsepower, or the developer you can throw at a problem who produces quality solutions ‘n’ times faster than his associates. They also often seem to be the kind of people who don’t enjoy developing business apps.
Obviously under scrutiny there’s a lot of overlap – but that’s just what leaps into my head when I hear either title… I’m not sure where/when I start developing those persona’s though. They probably don’t marry up with reality.
I think he's right too - GHD, as I see it, is exactly how he describes it: the ruthless pragmatist. And this is definitely where I see myself fitting in.
I think this highlights the problem tho - every ones view of what these roles are is different, and when it comes time to actually find a new position etc, recruiters and hiring managers usually latch onto whatever title they can - otherwise they would have to describe the whole job..... but without that full description, how can you tell if the person and job is a good match?
But his later comment about the levels and how people get them - as well as SM's comments about how it works in the infrastructure side of things - is both accurate, and scary:
My biggest problem is with Senior – Senior is totally screwed up title in our industry – I know plenty of other industries where senior means something… I was having a conversation with a nameless Dev Manager from a large Dev house in NZ recently where he has “Senior” developers who can’t even be trusted to complete simple tasks on their own.
Hell I became a Senior developer by the time I was 22, and I only officially entered the industry when I was 20… that’s ridiculous.
I've seen this too, and I think it's an ego thing in our industry - as Adam pointed out. Most of the people coming out of university with little or no experience (even if they have been cutting code for quite a while) don't want to be called "junior" - it sounds like they know very little. The problem, I think, is that in terms of code, they may know a lot, but in terms of business and world experience, they know very very little - but they don't know that they don't know it.
I've heard a lot of people throwing around the Apprentice / Craftsman / Journeyman / Master cycle, and while I think the idea is good, I've not always seen the "levels" applied well. I don't think it's something you can level up by just "doing" something and ticking off the card - nor should it be something you get just for turning up 9-5. Actually, especially not for turning up 9-5.
Oh, and I'm pretty sure there are no Master's in this game either. Software moves too quickly.
I think Alex is onto something tho, and it would apply to ICT people too (SM, what is the actual term for what you do? Infrastructure?).
-
If you are starting out, your are an apprentice. Some places will let you write real code, but if they do, it's checked by senior or "next level" people before it goes into the code base, or it's in a project which isn't critical to the system. You are basically being paid to learn on the job, but with a presumed base level of knowledge and with pay to reflect both sides of that - more than a building apprentice who's assumed to know nothing, but less than someone who's been thru the apprentice cycle. This is a more interactive version of whats now a junior. I'd expect most people to be in this "class" for 12-24 months, if not more, but their primary goal is to learn. But if they prove themselves, they gain more trust, and can do more without constant supervision.
-
If you get past that - and no, I have no idea what a good "level up" is, feel free to chime in - you are now a developer. You write code, but while it is reviewed before going live, there is a higher level of trust of what you are writing. Developers are usually the ones writing most of the code on a project. This is what is now an intermediate or low-end senior person. I'd expect most people to be in this category for 3-5 years, maybe longer. Their primary goal is to write code.
-
After that, you hit senior developer. All the hard, gnarly problems come your way, along with structural stuff so that the developers can keep going and build on a known-good base without worrying about the more advanced things which they are not proven in yet. Chances are, these people are talking to clients a lot, interacting with the test team(s), BA's, project managers etc, running code reviews, coaching, making sure the apprentice's are doing good stuff (and checking what they are doing), as well as making sure the developers always have stuff to do, but don't get bothered by the BAs, project managers etc. Deciding the components used in the project - do we need an ORM here? which one? MVC or something else? This is what I called the GHD.
-
After that? I dunno. Go start your own company or something.
So where does the "architect" fit in? I think that is exactly my point - for 99% of development, I don't think they have a place at all, at least not in the way they are normally thought of. SD's or GHD's would be doing a lot of what they are normally thought of as doing - the 30,000 foot view and interactions with others. Maybe there is a team of SD's or GHD's (or senior BA's, DM's and PM's) who come up with the basic design of the system before each moves onto their own specialist area to get down to the nuts and bolts - because I seriously doubt that one person can "design" the whole lot - code, servers, business analysis, project estimates etc. Better to do it as a team of specialist peers.
My point here is that a GHD or SD has skin in the game - they are a pig, not a chicken. The "traditional" architect doesn't have skin in the game, especially if they are throwing things down from the ivory tower. They are a chicken. And by the rules of scrum (and other agile methods): if you don't have skin in the game, how can you play?
And to answer Rowan's question ("Is the job title on your business card for your benefit or for others?"), I think it's a little bit of both - 10% it's for me, tho I think that used to be a lot higher when your business card got you in the door and meant something. 90% it's for others - what role does that person's company think they are in? Do they have a title perceived to be of prestige etc. I think in development, it's for other people, which explains why most developers don't HAVE business cards.
And whats on mine? My BBC one has "Architect" (and yes, I was "forced" to have a BBC one - not allowed to use my other ones for work stuff) as well as my contact details, but my personal one has no title at all - it's a moo business card with my name, phone, email, web address, twitter handle, linked in url (online CV), and a picture on the other side which I took, and means something to me (usually it's of New Zealand).I throw them away about every 12 months and get a new set, because something on it has usually changed - and I've taken better photos by then, too.
Gone are the days of looking thru a rolodex trying to remember who that person you talked to months ago was and what they do. These days, its all about the network - and for a network, it's all about trust and what I have done, not the title someone has given me.
