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.
