Chris Zempel

Junior vs Senior

It would be an understatement to say the hardest moment a developer faces isn’t when they know what to do, but when they don’t. And nowhere is this more immediate than early on on the process of learning how to code.

Most of the people you ask probably can’t give you advice thats very good, either. Not because they don’t know, but because the process of getting to the point they’re at means internalizing and unconsciously adopting a whole host of things. So you’ll get the “right answers,” but the information which needs to be the most emphasized is hit upon indirectly. The other barrier to good advice you’ll run into is the strong underlying desire for accuracy — so instead of a broad answer simply stated, you’re equally likely to get a bunch of situations where the advice you really need doesn’t apply.

Really, though, “What language should I code in?” “What framework should I learn?” “Do you think I should take this job, or that one?” all boil down to the same questions about the path of mastery:

Any advice that’s actually good needs to help clarify these for you.

What Does the Map Look Like? #

An extremely useful starting point is, what labels does the industry itself use, and why?

Well, to start, its useful to lump everyone into three categories. Novice (catch all for brand new or haven’t started), Junior, and Senior. And then, some companies use these titles not as reflection of any objective measure, but rather about your worth as a person and how well you manage office politics. So let’s just categorically eject this portion of usage.

Other companies use them as a representation of time. A junior is used to describe anyone who’s coded professionally for 3–5 years, and then someone who’s senior has coded for 10+ years.

“But Chris,” you say, and I pull a headphone out and glance over to listen, “What about a senior developer who’s been around for 10 years who’s horrible?” Wow. What a great and timely question for you to ask.

Another Dimension #

Obviously there’s another dimension here — how “good” is the developer? Given the same amount of experience and time, two people can spend 4 years hacking away at the same company and come away completely different in terms of efficacy.

What’s “good” consist of? We can usefully boil this down into two things: 1) actual skill (do you know syntactically how to accomplish this task in this domain, or how fast can you learn how?), and 2) experience. But what’s experience?

It’s simple. Experience is knowing where the mines are, so you can avoid stepping on them. Experience means you’re able to understand the consequences of the decisions you’re making now in terms of months, years, far down the lifecycle of the project.

But we still have the original problem: two people can have the exact same kind of experience, and come away differently. So what differentiates them? Again, this is simple — whether or not they learn from the experience. So it’s not experience itself that is important, but what it gives you access to, which is wisdom. Experience is the ore. Wisdom is the gold.

So time itself isn’t a sufficient measurement. There’s two other areas: actual skill, and wisdom.

How Can I Figure Out Where I’m At? #

So why is junior 3–5 years, and senior 10+ years?

If you ask what makes a junior developer, and what makes a senior developer, you’ll get as many answers as there are people. And it will confuse you (it confused me). So obviously these aren’t good questions. But asking what doesn’t make a junior developer is just as vague.

Let’s think about the stages of a developer in terms of what you can’t do without to move to the next level. If you can’t do x, then you can’t be considered y.

But does having the wisdom borne from having done all this make you a junior, or a senior? Well, that’s the real difference.

A junior has done a thing one time, and a senior has done it many times.

This makes even more sense when you consider that the lifespan of a project in the corporate environment these labels hail from takes ~3–5 years for one application in totality, then ~10 years for several.

So really, according to somewhat standardized corporate labels, junior or senior is really just, “how many times have you seen a project through in its totality?” That is what you should focus on.

The Missing Ingredient #

Since we’re measuring in terms of “projects seen in totality,” and the labels and measurements come from corporate businesses that need a way to filter and manage by the lowest common denominator, there’s still some missing thinking here. Time isn’t the most useful measure because it still doesn’t account for preventing you from becoming that horrible senior developer.

There’s something else that differentiates someone who is junior from someone who is senior, and that something else is “Independence.” A senior developer can take care of themselves in the absence of direction, but the junior can’t. Independence means delays in a project aren’t an indication of personal “weakness,” but rather just a temporary and interesting roadblock as a consequence of the domain complexity.

This is really important for your mental happiness, so lets dig into this a bit more. Every project, every company, every relationship will come with its own set of problems. In fact, if you’re programming something at all, its safe to assume that (hopefully) you’re doing something that by definition has never been done before (otherwise…why would you need to program it?). This means the point of introducing you into the process is to deal with the issues that come up. Your value as a professional and a human doesn’t rest in the problems you face, but in how you deal with them.

The new contract comes in, or I get my idea mapped out. I’ve got all the requirements sitting in front of me. You know the experience, and if you don’t, you soon will. The shift from junior to senior actually happens when you’re looking through the requirements, and your mindset switches, from “Am I worthy of this problem?” to “Is this problem worthy of me?” and you have all the wisdom needed to, in a practical way, pull this project off.

Where should I go next? #

The natural starting point is, can you build an application? So you’ve got your application. Now what? Well, you’ll need to be able to deploy it. Okay…you can hit a url, and see your app. Wow! But…wait, why isn’t this page working? It works in development…All right. Now you know what to do when the app goes down due to bugs. But wait…this is no bug. This is a user stampede! The app isn’t fast enough. Oh crap. What do you need to do to make sure everyone can use this? Now how do you roll in this new feature people want to PAY you for?

Okay. So you know what to do next. But this still doesn’t prevent you from becoming that horrible developer a decade later who’s stayed in their own bubble of ideas. What’s the key to being great?

Curiosity #

If you are curious, it means a couple things. You’re constantly taking in new ideas, keeping up with the rest of the industry around you. It also means that you want to find something out…which implies you actually like doing it. Which is dreadfully important — you can’t learn, or access your creativity, and stay relevant as a developer if you don’t like the projects you’re working on. Controlling this isn’t a selfish thing, in fact, its something you should insist on as you learn more and more about what you like and what you don’t, and your employers (if they’re good) will insist on it too because that’s the only way to get the highest quality of work of out of you.

I found that after 2 years of consulting, I didn’t like it. This is because the nature of it encouraged me to finish a thing as soon as possible to move onto the next one. This doesn’t jive with me — I want the feature I’m working on to matter in six months. The thing is, previous to this, I didn’t know anything, and consulting let me peer inside many different businesses and industries. So even though I don’t want to consult that much anymore, the wisdom it gave me access to was great and I’d definitely recommend consulting to anyone else starting out.

The Hardest Part #

The point of this blog post is to help you imagine who to become next in an extremely practical way. Hopefully now you see the practical reasons why the industry exists the way it does, but I have some final advice for you. Development is hard. It takes a while to learn. The capability you get access to as your skill increases with the computer as a tool is so huge, its frightening. That’s why people get paid so much for it.

The only way to propel yourself through the process is to care. This means following what makes you curious. But deep down, nobody really knows why they do what they do. Not really. Best just to admit this.

The rational choice in the face of this is to be as irrational as your practically can, because this will lead to the most experience, and in turn, the most wisdom. This means taking wild steps until you stumble onto your path.

And regardless of what technology stack you choose, or where you choose to start, you’ll need to be able to move up and down all of it. The question isn’t what, its when. And the point of programming isn’t to have a running program, it’s to accomplish something with it. So choose wherever is most fascinating, bottom of the stack, CSS, or right in the middle (that’s what I did), and start there.

You don’t need a job, a company, or a rational reason to build something and show it to other people. There is nothing between you and upgrading your wisdom and mindset except committing to the idea that its possible, and then following through. The hardest part here is truly, fundamentally committing to the idea at every level of your person before the external reality has verified what you think. Well, you have to create it in your head first.

Here’s the deal: as you get better, as you progress, there’s a story you’re going to want to tell yourself: “I know what I’m doing. I’m an expert.” In fact, you’re going to think this is what the external world demands of you. When really, to truly build great software, you have to learn a lot about each project brand new. Learning is a messy process. So falling into that trap of assuming you know what you’re doing, and that you couldn’t do better, will categorically make sure you don’t build tools that people really enjoy using.

Technology is a wonderful tool, but a poor master. It will do exactly and precisely what you say, so the responsibility for what it does rests only with you. And the truth is, when something blows up and doesn’t behave the way you intended it to, you can respond in two ways: you can own it, own the fact you messed up, critically examine it, remain in the right professional mindset of pleasant curiosity and healthy emotional detachment and grow, or you can get lost in the story of who you tell yourself you are and blame someone or something else.

But before any of that, you just need an idea you care about enough to help you struggle through the technical bits. If that doesn’t work, try a different idea, or different technical bits. Build something, show it to people, celebrate…then make it better.

You only have good choices. Make one, for yourself.

Then go.

← Home