How to succeed as a junior developer

Congratulations! You’ve been just hired as a junior developer. You probably went through one of those Javascript full stack bootcamps, finished a CS degree in the University, or self-taught your way into the profession. It’s all the same. Kudos.

What happens next? What are the pitfalls ahead? What’s required of me?

The advice that will follow is very personal but I was once a junior and, oh man, I wish I’ve read back then what I’m about to write here. With a bit of luck it may also help you. Part of my current job responsibilities involve mentoring freshly minted programmers through the mazes of our backend during their first few months in the company. This post is dedicated to all those new developers that taught me with their questions more than I could have learned on my own.

I got my first job as a developer in July, 2019. And I think I’ve learned a thing or two about on what it takes to thrive as a junior developer:

1. If you’re like me (meaning: not specially gifted for the dark arts of programming) then answer number one is time. You need time.

   Despite what you may have heard: No, programming is not for everyone. No, is not easy (outside of small pet projects). But the good thing is that if you are ok with being stuck for that many hours is because you like it. It should feel like a never ending string of little puzzles, each one leading to a dopamine hit and a tiny new learning.

2. Time how? Watching videos? No. Reading books? No. Following tutorials that will make you pause and re-type in your editor what you see on the screen? Mega no.

   There was a hint at the end of point 1: you need time being stuck at stuff a guide/mentor would consider in the area of your zone of proximal development. It’s the zone located between the ‘what you can do unaided’ area and the ‘what you cannot do unaided’.

   You need hours in front of the screen being stuck at stuff. Days, weeks, months. Many. There is no golden tutorial path that will spare you from this unavoidable truth. You need to get stuck. The good seaman/woman is known only in bad weather. If you feel like you’re cruising, then you’re wasting time. If you feel safe and cozy, you’re not learning.

   But why a guide/mentor? Can’t one figure that out on their own? Well, at the beginning it’s hard to even figure out what is it that you ignore. In other words: you don’t even know what you don’t know. Of course you can try and find that sweet spot on your own, but as someone that wasted a lot of time trying to do so, I would suggest you to get a mentor/guide. With a guide you will be frustrated at the right stuff every time (which will lead to learning), instead of frustrating yourself from the possibility of being productively frustrated because you are trying to do stuff that’s way over your zone of proximal development. It’s all about productive frustration.

3. Avoid OCD. No, you won’t know all you’re doing. In the beginning not even in a smaller scope. Programming is all about encapsulation. Smarter programmers encapsulate complex stuff so we, mere mortals, can program stuff. You and me are on the bottom rung of the encapsulation food chain so only get obsessed about what you need to move on to the next error message. There will be time to get a comprehensive and thorough view. But that is not now. You will learn stuff while in the process of needing that stuff to solve the problem in front of you. And don’t worry, you don’t need to memorize anything, the pain will make you remember your hard-earned lessons learned.

4. As a slight counterweight to point number 3, you do need to start to cultivate a certain degree of technical sophistication. It shouldn’t be a mere copy, paste, execute and run away. Technical sophistication is a concept I stole from, Michael Hartl, a true master teacher of programming. I quote:

   Knowing how to code is an important component of technical sophistication, but there’s more to it than that—you also have to know how to click around menu items to learn the capabilities of a particular application, how to clarify a confusing error message by googling it, or when to give up and just reboot the darn thing.

   My take on technical sophistication has two main components. This point (number 4) is about the first of those two, which is: being tech-savvy, tech oriented, tech fearless, tech curious. I don’t have a single catch-all term for this. It’s an attitude. In general, ideally, technology should bring you joy. And I’m not talking with this about the joy of coding (which, again, is pretty much mandatory if you want to do this eight hours a day for several years on), but I mean it in a more general way.

   Perhaps the best way to illustrate this attitude is with a contrast: My mum is terrified by technology. She treats her cell phone as a bomb that will explode if it’s even slightly mishandled. Going to the ATM involves as much stress as actually robbing the bank.

   The opposite attitude is feeling something like “let’s see what we can do with this shiny new thing”. People would say ‘a hacker attitude’, but tech culture has pretty much ruined that term (along with ‘rockstar’ and ‘ninja’) so I prefer to skip it.

5. The second component of technical sophistication is quite complex to acquire and it leads us back to the necessity of spending time blocked/frustrated while building actual stuff. This second component of technical sophistication is all about learning WHEN to ask something and WHAT to ask. I would say this is the ultimate skill a junior must master in order to eventually move on to a mid position. Your success as a developer mostly relies on perfecting this skill.

   This point (number 5) is about the WHEN. Should I stop now and ask for help? Should I keep exploring this wall a little bit more? Tread lightly, if you ask for help too soon you may have wasted an opportunity to learn something that will get ‘stuck’ with you (pun intended) if the problem was actually within your grasp. On the other hand, wait too long and maybe you’ll end up discovering that you never had a chance to solve it in the first place (which will uselessly frustrate you). It’s a bit like approaching an actual wall in an extremely foggy weather, you really can’t tell how high is it before attempting to climb it.

   As you move towards the stage of conscious incompetence you will be able to at least know what you ignore, and the WHEN will be clear, but that takes… again… time.

6. WHAT. So you need some help. You google, request help from your human guide, ask Chat-GPT. But how to do that? Ideally, you know your way around English quite well, since you need to be able to at least troubleshoot as a native speaker. And not only that but also the more technically precise you are with your words the better. You’re probably at a stage where you will need several pre-searches as you progressively learn how to actually pose the question in a manner that will output useful and relevant results. Until that happens assume you’re probably searching for the wrong thing.

   You should feel like a wizard chanting an invocation to summon a beast from the other world. You need to get all+the+right+words, otherwise you’ll only get a little bunny from a hat.

To recap: you need time, lots of it. Time DOING stuff that is slightly above what you can do unaided. For that you probably need a real life human guide/mentor. Don’t get obsessed over all the details, you’ll learn stuff as you need it. But be curious and enjoy messing with shiny new stuff. Ask for help if the excitement of the puzzle is turning into sour self-hatred. And get increasingly better in knowing how to search for solutions. Ideally you will go through a never ending string of blockages followed by Eureka moments. At the end of each ‘Eureka!’ you should have learned three things: to solve the specific thing, to get a blurry idea on how to solve similar stuff in the future, and finally, you should have learned to search related problems with all the precise technical terms.

And don’t forget to have a laugh as often as possible. See you on the other side!