I think of the titles I’ve had over the course of my working life in tech. I’ve been a “programmer/analyst”. I’ve been a “project leader/system specialist”. I’ve been a “software developer”, a “senior software developer”, a “software engineer” a “senior software engineer” a “staff software engineer” and a “principal software engineer”.
And all of these were in no particular order.
I’ve reported to “chief programmers” and “lead developers”, “delivery managers” and “engineering managers”. I’ve reported to CTOs and VPEs and SVPEs.
Once upon a time I even asked for a specific title. It was “Duke”. (No, they didn’t go for it.)
OK. I have questions. What, for example is the difference between a “software developer” and a “software engineer”? Does one drive a train and one takes a lovely piece of land, destroys it, builds a bunch of houses or other buildings and then name it after the loveliness that used to be there? What does senior mean? Does it mean getting a discount at the waterpark or just indicate what the holder of the title was a senior in school more than a year before? What does it mean if you have more than one “principal”?
Yes, I know. If you look — even just a little bit — you can find endless “career development matrices” that connect (usually) very specific attributes to each of the gradations, attributes referring to independence or achievement, knowledge or the ability to recite what amount to passages from annointed texts about design or process.
We have a need for public differentiation it seems. We want to have a pecking order — though, at least, it’s better than the pecking order that was established on the seventh-grade schoolyard. And it’s specifically public, as opposed, for example, to the numbers on one’s (today virtual) paycheck.
I see this from the career development angle. These days we move around. The ability — nah, make that the near expectation — for us to do so is one of the things we value about our profession. We’re not so locked in. Titles provide a kind of currency when making such moves, a shorthand for evaluating individual’s abilities.
Big companies always had these gradations. In an organization of thousands, having a level-designation for each cog in the machine is a useful, even necessary shorthand. These days, though, it seems to be all the rage for smaller organizations as well. Does it stem from employees wanting to know where they stand? Does it come from the multiplicity of strata in our current society? (Where there was once first class and coach, there is now first class, ultra class, economy, economy with extra room, economy with the luggage, economy without luggage, cattle car, sardine can and….well, I digress. Or, alternatively there’s regular old highway and express lane for when riding in the regular lanes would be, so, so…)
Some of the best organizations I’ve been in took the opposite approach: there were developers and there was the lead developer. We all committed code. We had differing abilities. And everyone knew where people’s strengths (and weaknesses) lay. You knew who to go to if you had a question; you knew who might need a little extra help in a given area. It wasn’t a problem, and it promoted a certain cohesion that tends to be lacking when titles become nearly visible, if virtual, insignias and deference becomes the norm.
But, when it comes down to it, we’re all programmers. We create and extend products; those products consist of code. It’s what we do. The other artifacts of our work are just that: artifacts. It often seems that remembering that would do us well.