This is a pretty universal truth, most developer titles are complete and utter
nonsense. Shit like “Junior Developer” and “Senior Engineer Level 2”, sounds
like we’re playing Dungeons and Dragons. Sad part of this is, most people will
say they don’t care about titles but then they are quick to slap “Senior” in
their email signature because deep down they really care. Most of us are pretty
fucked up creatures struggling to figure the world out so I get it, something
as silly as a few words to describe you can be important and irrationally
meaningful in some way.
I’ve been fortunate enough to have jobs at startups where not only did titles
not matter, but I’ve been able to come up with whatever zany hipster shit I
wanted. For one of my side companies I am currently serving as the Chief
Alchemist, got another stealth project that will probably end up with us
founders with titles with the word “ship” in it. At the end of the day, that
shit doesn’t matter.
In a stuffy corporate environment, it matters a ton because those titles are
often tied to pay grade. Hate to break it to ya though, pay grade is dictated
by negotiation skills and a willingness to turn down an opportunity if the
salary isn’t what you’re looking for. I get it, sometimes those once in a
lifetime opportunities come up and may have to work for below your billable
rate or even for nothing at all while things ramp up. If I had to guess, those
opportunities probably don’t come chained to cubicles, so my statement stands.
As I’ve recently switched jobs (feeling more like a life experience, but that’s
for another post), actually as I’ve switched jobs a few times in the past year,
I’ve gotten the experience of starting from the bottom again. Not as in I
switched careers or anything, but just in the fact that I have started fresh
on existing projects with no background on them aside from the technology being
I was a newbie and I took the opportunity to explore what that really meant in
regard to titles and skills and such. What I realized, aside from titles being
total grabage, is that everyone goes through a (albeit usually) short lifecycle
as a new developer.
First, you start off barely crawling, you’re a noob and you may know how to
code in XYZ language or even scale ABC technology to the moon, you still don’t
know jack shit about this new system you’re working on. Even worse, if this is
an industry you’ve never worked in before, you probably don’t know the jargon
either. Charlie Brown’s teacher probably makes more sense then your co-workers
at this point.
Graduation from a newbie can take anywhere from a few days to a few months
depending on your skillset, the overall complexity of the system and most
importantly, your willingness to adapt. Many people get stuck in noob land for
a long time because they already know it all and have to do things their way.
Knowing concepts and having your own opinions is great and all but no one likes
the guy that has to come in and rewrite everything or is unwilling to work with
an existing system properly. No one asked you to re-architect a damned thing,
they asked you to fix some bugs so you can learn more about the system.
Producers are important because they may not know everything about the system,
but they know enough about the system to be able to troubleshoot issues in a
timely fashion. I’ve said it before, the ability to troubleshoot and resolve
issues is by far one of the most important skills that I feel too many people
Not much of a lifecycle, I know, but for the sake of keeping it simple, I opted
to not go into more granular detail. Sure you could slap in another iteration
after producer to describe your most senior of developers. Don’t dare call them
tenured, none of this has to do with time spent in the trenches. Sure, your
most experienced developers will generally be the ones that have been around
the longest but that is experience with the current system. I know I’m not
giving much credit to outside experience, but it’s just as important when
solving new problems. At a certain point you want to build a team of people
that can solve new problems as well as maintain the old system. Way too often
there are systems that pre-date an entire team yet they are still being used
and thus need to be maintained.
You may have noticed that this lifecycle didn’t include titles, that was on
purpose as titles tend to be arbitrary labels at a specific organization.
Nothing urks me more than when a recruiter reaches out to me based on the
positions I’ve previously held. The titles range from things like Senior Web
Applications Developer to Systems Architect all the way up to Chief Technology
Officer. If you were to drill deeper into what my duties included for each of
those jobs you’d notice a pattern, all I did was kick ass and ship code.
Stay tuned next week for part 2 of this post where I discuss a better title /
naming convention that can be applied to any shop. I mean, that is unless my
buddy [Justin][justin] doesn’t post on the topic first 😉
If you’re not on my mailing list, you should be, then you will get part 2 sent
right to ya next Monday!