Josh Sherman
Last week in part one, I discussed the lifecycle of a developer that just started a new job. The gist was that when someone starts a new role at a company, they generally have to learn the lay of the land. Regardless of their technical prowess there is always a bit of learning curve to become a producer / go to employee for the company.
To follow up, I wanted to discuss a more universal title convention that could be applied to developers. It’s easy to get roped into the complexity of roles and titles and responsibilities, the fact is, most roles are really just descriptions for the department that someone functions in. The titles I am going to discuss could simply be appended or prepended by the department name if need be.
Right out of the gate, the easiest way to go about things is to start with the role. For me, “Developer” is sufficient enough to describe a programmer in an organization. Some would argue for “engineer” while others would want to try to seem trendy as shit (you’re not) and go with “Hacker” or even worse, “Ninja” or “Wizard”. So for the sake of simplicity, I’m sticking with Developer.
So everyone is a developer, but what if they primarily do DevOps shit or customer support or something like that? Well if their primary function is DevOps why not make that their title? Job titles shouldn’t be cryptic and have to be explained, they should describe the function that is being performed more than anything else.
How do we tell the difference between Pat that was just hired and Sam that has been with the company for 5 years and is quite the linchpin? Guess what? You don’t fucking need a title for that! They are both developers, that is their function. Saying someone is senior or level X is really just saying that they have been with the company longer. That tenure implies that they know more about the system than someone new. Do they know everything about the system? Possibly, but also, maybe not. If you were to list out everything that someone knows as part of their title you’d end up with pile of shit like “Lead Software Engineer Level 9000 / DevOps / Back-end / Front-end, MySQL…”.
It’s easy to fall down the elevator shaft of ridiculousness, fortunately this generally isn’t how companies assign titles. So it still begs the question, how do we tell Sam and Chris apart? Believe it or not, you really don’t need a title for that. Does Chris report to Sam? If so, Sam has transcended Developer status to being a Manager. You could go as far as saying Development Manager or Product Development Manager where Product is a company-specific product. Even then, outside of the company, that product is meaningless and has to be explained, the whole point here is to make things easier to understand.
But Sam and Christ are peers, how do we tell them apart? Do people run around addressing people by their titles? Aside from people closer to the top of the totem pole, there’s a good chance that most people don’t know what someone else’s official title is. Project mangers, developers, IT, support, marketing, et cetera. People’s titles end up being their department / job function. There’s not a damn thing wrong with that and just goes to show how job titles occur naturally in the wild jungle of the cubicle farm.
So if you’re still hung up on how to differentiate Sam and Chris here’s some job functions that I was discussing with my buddy Justin a while back that sum up the three primary roles of developers:
Grunt
Not the most appealing title, but it seemed better than “unskilled labor”. Grunts are your new hires, they know how to code but they don’t know shit about your system. They can do basic tasks and that’s what you give them. You give them progressively harder tasks as they learn the system. Over the course of a few weeks to a few months they are able to knock out most tasks without asking questions and really know their way around.
Troubleshooter
Probably could have stuck with the military references, but I wanted to be a bit more descriptive with the role. A troubleshooter is someone that’s learned their way around the system but also holds the special ability to be able to identify and isolate issues. Every troubleshooter has to do grunt work, but not every grunt can troubleshoot. These individuals end up being the key employees that other employees ask questions to.
Designer
I’m not referring to graphic design but instead, system design. Systems architect, systems designer, whatever, their function is still the same. The designer knows their way around the existing system and been around long enough to know the issues with the existing system. Grunts ask them questions and need their help troubleshooting problems and they still get into the trenches and do grunt work.
Not every troubleshooter is cut out to design a system, and there’s nothing wrong with that. Sadly, I’ve been witness to a company that allowed a grunt to take on the role of a designer. Never in a million years would I let someone that can barely understand the existing system (it was common knowledge that he was not a troubleshooter) redesign the whole damn thing.
As mentioned, every role does grunt work and that’s fine. Some people end up growing into the other roles and others just end up remaining grunts. That’s okay as well. What’s not okay is when someone doesn’t catch on to how the existing system works after an extended period of time. As shitty as this sounds, not everyone is cut out to be a developer. That’s also okay, as I’m not cut out to be an NBA anything. Just gotta find your niche.
I know the roles I defined here are extremely limited and you may not feel like they cover every single developer in your organization. That’s fine and I get that. I did purposely leave out describing specific tasks and technologies because I feel that developers should be able to adapt to different languages and technologies and own the stack. I’ve grown to hate the term “full-stack developer” because I believe that knowledge of the full stack is just basic aptitude that every developer should have. Yes, asshole, I’m fully aware that at the time of this writing my little author blurb mentions me being a full-stack hacker ;)
Back to titles and all of that nonsense, the fact is, regardless of job title, you still have to explain what you did at a company during interviews and such. Perhaps we could go as far as throwing titles out entirely and simply discuss our roles with an organization. If nothing else, it would cut through the cutesy fluff.
