My current title at work—what I will regard here as simply an "ongoing clerical oversight"—is Junior Developer. Having provided over three good years of service in this role to date, I feel there may be value in sharing my thoughts on the title itself, and the implications it has on the professional life and development of any person with a
r in front of their name.
Labels & Morale
What exactly is a junior developer, and how does the position differ from a mid-level or senior development gig? From my experience, the short of it is that these lines blur to become negligible as time goes on. Furthermore, such distinctions are not necessarily earned nor deserved in all cases. Or to actually keep it short as I just now promised: No inherent difference.
But let's explore this. First off, I suspect there are about as many nuanced definitions as there are employees with the prefix. Even so, shoot a query through your engine of choice and it will yield just heaps of stuff like this:
A Junior developer will need near-constant help. [ ... ] They don't know what they don't know, so without guidance, they will make frequent mistakes which, if not kept on top of, will derail the wider team.
In fairness, the answer referenced above does express the position that perception will vary by employer and employee. But alas, this sentiment that a junior developer is essentially like a "development trainee"—the original title they made up for me at this company, in fact—is echoed all over. Therefore, one could assume that it reflects real-world perception (and by extension, as they say, reality). My humble opinion: kinda sucks.
I would propose a different, multifaceted interpretation based on my experiences to date, and I find definitions like the one above to be quite damaging to morale and professional image after a while. For me, with over three years under my belt on a single platform, I would not for one moment consider myself a developer who requires near-constant help or close supervision. Guidance is always good, though. Accept it and grow.
By maintaining a junior role while my own output is objectively on par with my senior friends at work, I'm effectively short-changing myself. I'll hazard a guess that there are others—hard-working technicians with no shortage of skill or knowledge—who feel a touch slighted by their lack of progression on paper.
These frustrations grow with each reminder that a title is more than just the words in your signature, but a designation with far-reaching implications. If I write this right and don't botch the cadence, this idea will be the chief takeaway from the whole article: With linguistic connotations that manifest in perception and social reality like all other words, labels do matter in immeasurable ways, and it's up to each person themselves to accept or reject them as they come.
Pay Grade & Mobility
Compensation is among the worst kept secrets on my team. My current salary is $55k USD, about $30k less than the next lowest paid, and then a whopping $40k less than another developer with identical responsibilities who began just nine days before me. I realize that will come off sour, but I mention here because I think it's important to illustrate what discrepancies can exist in the real world. I will say now that my coworkers are all highly capable and produce excellent code in most all cases, and in truth they are more punctual and professional by any conventional definition, so they absolutely deserve what they make. That being said, my output has never been some tiny fraction of theirs; it is regularly on par and frequently above average for our department. So, what happened here?
In my case, it's abundantly clear that the title is rooted, at least in part, in my personal shortcomings of negotiating prowess, and this further boils down to a lack of experience on that front. It is often suggested to me that the only way I will truly enjoy upward mobility in this field is to use my current job as a stepping stone. I mentioned this to the CEO and COO of my organization and was given a $15k raise within the hour. This was actually meant to come with a title change. That title change was never processed by HR, slipped through the cracks, and they've yet to sort it formally. Could this be a good thing? For a while, I thought it could be.
At my current pay rate, I figure (perhaps erroneously) that it will be much easier to score another substantial raise if I'm able to wrap it up in a title change. In fact, I chose this title for that reason when it otherwise would have been "Developer." So far, this has proven ineffective. Considering what limited info an American company is allowed to disclose to new prospective employers legally (i.e. years of service and current title), I am now in a weird position where I can't seek new work with confidence. I lack a verifiable instance of real-world experience where I managed to climb the ranks from beginner to anything but. No evidence of growth.
Pride & Malleability
This is where things get good, like for everyone. As a junior developer, or even just a young developer with spirit, I am in what has sadly shown to be a non-universal position to learn and grow with an open mind. I have seen three other employees come and go from my team, and all three sank because they were too proud to accept help. This is one of the strongest mutual benefits of hiring someone new, as in junior, to begin with.
By remaining malleable and listening to teammates, owning up to bugs and mistakes or any gaps in knowledge that impede development, a junior developer is in a better place to succeed than any senior developer who is stubborn and stuck in their ways. It's easy to ask for help when that's what's expected, but this brings about another point about labels: a Senior Developer isn't expected to know it all, especially right out of the gate, just like a Junior Developer or mid-level teammate.
Corporate software projects are often very large and dauntingly complex, certainly compared to anything the average person would produce on their own. Moreover, huge code bases and data models aren't always documented so well (or at all) for those new devs on the block. Anyone walking in on an old software project needs help, and there's nothing bad about it.
But this super simple truth eludes so many I've met, even at management levels. Assumptions tied to titles can cause some to wind up getting nervous about image, and then flounder to save face before eventually sinking at the employer's expense as well as their own (not just financially).
Thus, that stigma on the other end prevails in wasting resources, and it causes damages to an employer that I'm willing to bet are comparable to the financial struggles of underpaid workers with lesser labels.
Hopes & Dreams
I maintain that any developer worth their salt (junior, senior, or otherwise) is one who doesn't mind the title, but also doesn't use it as a status symbol or to justify non-cooperation. Despite my gripes in this post, I wear the badge with some pride. I flaunt it in my signature, usually tongue-in-cheek (as in: "hey, still haven't changed my title here..."), but other times to advertise that I am open to change, receptive to new ideas, and hungry for guidance. Not always, of course, but I do try to live and work by these ideals. I think this is typical of a junior developer.
If I am ever in a management position over a team of devs, I certainly like to think I will use my experiences as a long-term junior developer to shape my strategies at that time. Namely, all junior developers and beyond would all have clear paths for progression, these preconceived notions surrounding rank and ability by title would be eschewed vocally as a core value of workplace culture, and all teammates will be equitably respected and compensated fairly (so long as they are of this same mind).
I say this easily since I'm not in that position, and only more experienced readers could say whether or not I am describing a perfect world. I'd be curious to find out how this post reads to anyone who is in a management position, or a position similar to mine. Feedback way more than welcome.
Any thoughts on the topics here, and any feedback on my writing style and manner of presentation (including my admittedly lazy line art that I'll update soon to work in dark mode), would be enthusiastically received.
At any rate, thanks for reading my first ever blog post.