Our industry is batshit crazy. No point in denying. What we do (services based on pieces of software) is so multi-dimensional that sometimes it's damn hard to find a common denominator between two: people, projects, products, architectures, methods. Obviously, it's got its pros (let's leave them for another story ...), but there are serious cons as well - one of them is related to job titles, roles & functions:

They mean nothing. And they just don't work these days.

But we stick to them, because we're fully convinced that we still need them. In recruitment. In compensation (differentiating the salary for different people). To motivate people with career progression (even if it's just an illusion ...).

Sadly the way they (titles, roles, functions) are right now is ...

... flawed to the bone

Examples? Here we go:

1. Who's an 'architect'? Is he supposed to code or not? If he's the one that designs the systems - where's the border between the designer / designing developer & architect?

2. When does 'junior' become a 'senior'? If I'm just 1 year after graduating, but I've spent this year on very active diving into the guts of ASP.NET MVC & I know every littlest piece of it - does it make me 'senior' already? 'Senior' for MVC & 'junior' for the rest?

3. Let's take two devs - both with the same length of professional career: one's a generalist, another one a T-shaped specialist (an expert in one, narrow tech that knows the very basics of other stuff as well) - how do we emphasize the difference between them & their specifics (they can both be awesome & very useful, but their presence may be differently desired in different scenarios).

4. What about the level of responsibility - if there are two experts with the similar level of theoretical knowledge, but while the first of them had only created small, intranet noone-cares-much-about apps used by 10 people, the second one has spent his time on building business critical, highly-available systems for millions of people? Would you trust them both equally? Entrust to them the same missions?

No two look alike

This is just a beginning, the first things that usually come to minds. But there are far more dimensions to get covered:

• some people work on designs created by someone else & some take the full responsibility from the very beginning
• some people just create software & pass it through to someone else (so obviously, such critical aspects like maintainability are far to the bottom on their priority list), while some support their own products (which is a completely different breadth of experience)
• some people take full responsibility for the quality & some have the ass-covering buffers in the shape of manual test slave farms ...
• etc.

All these people do the software development, but there are various aspects of the craft that may either be completely ignored or absolutely critical in they way they do their work (or at least did until now) - don't you want to know these aspects when you recruit a person?

Please, keep in mind that we haven't touched any particular technology at all.

So what we do? We usually put everything we can in our titles, creating a patchworks like the one in the post's title ...

Ideas, anyone?

No, I don't have any simple fix on my mind. I'd glad vouch for title bankruptcy, but I don't have any better nomenclature up my sleeve. But ...

... maybe it's one of these problems that shouldn't be solved in the straightforward, direct way, but need some out-of-the-box thinking instead?

Let's consider this for a moment: are we that special / different from other professions? Can you classify precisely:

• journalists?
• artists?
• doctors?
• philosophers?
• or even salespeople?

Neither of these professions feels like army with a strict hierarchy - yes, they are specializations (like in software engineering ...), particular appointed roles (like in software engineering ...), even honorary titles (ok, this doesn't happen in our field ;D), but in general - these professions are very broad & cover plenty of different career tracks / attitudes / etc. that sometimes differ very, very significantly (like in software engineering ...). And still they manage without much whining.

Maybe it just means that instead of trying to pidgeonhole ourselves, we should change significantly the way we recruit / compensate / reward people so we don't really need all the nomenclature mentioned above (at least not that desperately)?

To be continued (soon)

Pic: © matiasdelcarmine - Fotolia.com