Why you shouldn’t think of yourself as a junior developer
A lot of young people will graduate this month and start looking for a job. They’re polishing their LinkedIn profiles, deleting those beer-bash photos from their social media accounts, and deciding on a career path they think will bring success. In a way, entering the workforce is a bit like attending a Halloween party: “What should I go as?”
If you’re entering the tech workforce, you might be wondering if you should go as a “junior developer.” Well, there is a lively debate online right now about this very topic.
One side says emphatically no, you should not. “Seriously, don’t be a junior developer.” This side says, you should learn to code on your own. Do some side projects and don’t enter the workforce until you’re at least an intermediate coder or a solid plain coder with nothing junior about you.
The other side says yes, go ahead, be a junior developer. Although they admit it won’t be easy. “For the junior devs out there, it’s going to be hard to land your first job,” they concede, but it’s not your fault. The industry is to blame for the shortage of junior developer jobs. Companies think it takes so much time and money to train junior developers that they only list positions for senior devs these days.
Before we go any further on this topic, let’s take a step back — way back. Let’s first talk about the society we live in and let’s start with the role that privilege plays. Some people are bestowed with the privilege of being hired as coders — in fact, I’ve argued publicly with Google about its hiring process. Some people also have the privilege of being well off. They can afford to be unemployed long enough to interview wherever they want, rather than take the first job that’s offered. This privilege of being able to coast doesn’t get talked about enough.
A corollary of coasting is the side project. “Do a side project and improve your skills,” says the no-on-junior-developers faction. But side projects take time (often free time), and time is not a privilege many people have. Not everyone can live in their parents’ basement while they work on a side project. Like me, for example. My family didn’t even have a basement. Actually, I take that back. We did. We lived in a church basement when I was a kid.
What I’m saying here is that economic privilege is a real issue when it comes to the whole concept of junior developer. Although, if you are bestowed with privilege, there’s nothing wrong with that. In fact, maybe you owe it to your parents — or your grandparents or whoever — to put your privilege to good use.
I don’t like the term “junior developer.” I think we should title such positions “apprentice developer,” because it’s not about the quality of the developer’s output — it’s about the amount of supervision they require.
You can have a senior developer who’s lazy or not detailed-oriented or undisciplined. One of the smartest coders I ever worked with, if you didn’t supervise him he’d go off and write a compiler.
He actually did on one project. We were trying to get him to put together a scripting interface, but he wrote an entire language and a compiler for it instead of the browser plug-in we needed him to build. So in my book, he was a very senior coder but still an apprentice because he needed so much supervision.
But there are other reasons to stop using the words “junior” and “senior.” For one, they imply old and young. For another, they imply male. In a family, women are never junior or senior. The titles “junior developer” and “senior developer” indicate on their face that we’re talking about men, and there is undeniable gender bias attached to them.
By contrast, “apprentice” is a meaningful title — for the developer and the company. And if the company has carrying capacity, it’s a great way to grow talent. Although, proviso: the apprentice has to be apprenticing in skills they can learn, not skills they’re never going to master. Some minimum level of aptitude is required.
And now that I’ve provided my context for the “junior developer” discussion, let me start by saying to those of you graduating now: my advice to you is to ignore the interview process and go after the job you want. When I came out of school (Maxwell International High School in Shawnigan Lake, British Columbia) I decided where I wanted to work, went there, and told them I was going to work there.
Remember that the skillsets you need will change. It’s actually easier to follow smart people into new fields than to chase fields. If you have privilege and you can go chase what you want, decide literally where you want to work (technology, geography, and the sign on the door) and then figure out what you could do for them that would make a difference.
I have done this. I took a one-way bus trip to rural Iowa, showed up at this gaming startup, and just started fixing stuff for them. At the end of my first day, the CEO offered me a job. I showed them not only could I do the work, I could figure out what work needs to be done, which is always the higher-value item.
I learned a lot there. But most young people don’t choose the job where they’re going to learn the most. They choose their job according to what it pays, or maybe where it’s located (i.e. not Iowa). That’s totally fine — but realize that sometimes the job that pays more won’t be where you learn more — and if you’re okay with that decision that’s great. But every time I had a choice between making more money or learning more, I opted for learning more. I was always willing to leave quickly and do things I was terrified of — and I’d encourage you to do the same if your goal is to learn. Most folks don’t, because this is irrational — but in the context of coding, it isn’t.
Again, don’t think of yourself as a junior developer; think of yourself as an apprentice. And you’re apprenticing for more optionality in the future so you can make better money and work wherever you want.
To be a successful apprentice, you should learn how to self-educate and how to ask for help. I have a friend who was an acupuncturist, and he decided he wanted to be a coder. At the time, he had four friends who were coders and, when working through a tutorial, he’d need to pose some basic questions. But he made sure to spread his questions among the four of us, so as not to overly pester any one person. He was willing to self-educate and work through the tutorial, but he was also strategic about asking for help when he got stuck.
That’s the same approach you should take when you’re apprenticing in a workplace. Try to do it on your own, but ask questions if you’re stuck for more than five minutes. Don’t spend a day being stuck, because that’s a waste of time for you and your employer. Don’t pester people, but find that middle ground. Make sure your questions get better over time, and that you’re not asking the same questions over and over again. That’s annoying.
If you take away only one thing from this piece, I hope it’s this: there’s no such thing as a “junior developer,” there’s apprenticeships — and either you’re either apprenticing towards a lifestyle you want or you’re apprenticing to position yourself for a future opportunity. Neither choice is wrong or right, just decide for yourself which is yours and don’t let anyone call you “junior” along the way.
Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced, and incorporated continuously through development and innovation, because good software is never finished.
Dear Graduates, You’re Not “Junior Developers” was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.
