Seven Tips for a Junior Developer | Pearl Leff

At my first internship, I was really clueless about what I was doing.  I was only a year into college, and interns often don’t know much, but my lack of knowledge took the cake. Once, I couldn’t figure out why my calls to my backend weren’t working, and finally a senior developer sat down to help and ended up having to explain to me that… the server needed to be running. 

By now, though, I’m a veteran junior developer. I’ve done five different internships over the course of my undergraduate years, which means I’ve onboarded to a new codebase five different times, used five different tech and DevOps stacks, went through five different types of documentation, and interfaced with five different company cultures. Each time I took note of what techniques helped me onboard and get things done the fastest. Over the course of these internships, I went from completely clueless to what I like to think is vaguely competent. 

The good news is that you aren’t going to need all that junior developer experience, because you can learn the main lessons from me instead. Here are seven important things I learned from my junior developer experiences. 

This is something that senior programmers know and junior programmers don’t. When I first started programming and had a problem, or was trying to add an existing feature to a codebase, I would google what I need to do or an error message and go straight to the first Stack Overflow link, which more often than not solved my problems. 

After a while, though, I started to realize that doing that made my understanding of what I was doing nonexistent. And if I wanted to slightly modify the code I copied and pasted from Stack Overflow, I couldn’t – I would have to try and see if someone had asked that marginally different use case somewhere else on Stack Overflow.  

Now, I always do a five-minute reading of the documentation. That’s not a metaphorical five minutes: I actually look at the time on my computer, read the documentation for whatever I’m using, and keep reading until my five minutes are up. After that I’ll allow myself to check Stack Overflow, but more often than not I’ve developed a deeper interest in the background, approach, and philosophy of the service or language. Often I don’t even need to look at Stack Overflow anymore, and if I do, I understand the solution much more easily. 

Learn to read Wikipedia, and if that doesn’t work, read Simple Wikipedia, and if that doesn’t work, google “Tutorial of <topic/language>” or “Introduction to <topic>”. 

You probably studied for interviews by forgetting that the standard libraries exist and implementing data structures yourself. But once you’re actually programming, it’s crucial to have a sense of what a language provides for you. This is especially relevant if you’re using an IDE that comes with code completion, like Visual Studio, IntelliJ, or Eclipse - they make it possible to develop for a long time and still be unfamiliar with the standard libraries. Read through language references like the Java API specification, Python Language Reference, or Ruby Documentation. Know the data structures your language gives you: what methods are available for an array, a dictionary, a stack, a queue. Read through the calls you can make for an API and the parameters you can pass to a function.

Try to commit these things to memory if you can. If you have to remove an element from a list, try to guess whether you should use poll(), queue(), removeLast(), or pop() before using code complete to figure it out. Once you have an internal sense of what structures do what, you’ll be able to code ten times as fast, because you know what you do and what you can’t and you won’t need your IDE to tell you what’s possible. Your code will also be much more powerful, because you’ll be able to harness the full capabilities of your language and libraries. 

I used to see the plethora of anti-cellphone and anti-social media articles on sites like Medium and the New York Times and scoff at the Luddite authors and their primitive understanding of technology. My phone was on silent and it didn’t disturb me in the least while I was working. 

Then one day I bought a phone with a terrible battery (in my defense, it was $40) and began to turn it onto airplane mode during work hours to conserve battery. Wow - what a difference! All of the sudden, my focus was qualitatively better; I was writing better code faster and getting much more done in a day than I had ever been able to before. This is important advice: stay off of your phone, reddit, Facebook, and anything else you spend time on. There are many site-blocking browser extensions that you can install to help you remember. 

You are going to spend a lot of time blocked: being stuck, not knowing where to turn, and not wanting to bother the senior people on the team. Most companies don’t have the kind of extensive documentation that would be needed to fully understand how their internal codebases work. Here’s a tip: your fellow full-time developers don’t really want to be bothered to help you until you’ve tried all other possibilities. So here’s a list of resources you can check to find solutions to problems.
You also may want to quickly confirm with someone more senior that you're trying to solve the right problem, and that you're trying the right things - you wouldn't want to spend a day trying to unblock yourself only to find out that you had gone down an irrelevant rabbit hole.  
This is the counterpart to the previous point. As mentioned before, you will spend a lot of time blocked. Unfortunately, that’s part of the process of becoming good at what you do - figuring things out for yourself and working independently is what enables you to understand the systems and logic of what you’re working on. At some point, though, you will need to ask for help, and even though they’re intimidating, senior team members are generally happy to help and teach you new things. Here are some tips for optimizing the “asking for help” process.
And of course, once you’ve solved a hairy problem, document the solution - for yourself, your team, or publicly - so that other people won’t be stuck the same way you were. 
There are a couple of reasons why this is important. 
A great way to engage with the tech community is via email newsletters or podcasts. Try to maintain a stream of news about your specific technologies (“React”), line of work (“front end development“), and computer science as a whole. Some great generalized tech sites to follow are Hacker News and Lobste.rs. 
If there’s one thing I consistently see with interns and junior developers, it’s an intense, all-encompassing insecurity about their lack of knowledge and low output. My advice is to calm down. Everyone around you had to go through the process you’re going through at some point, and just like them, you’ll be really good one day. This is what makes computer science such a humble and helpful field - the only way to get good is to program, experiment, and make mistakes, and there are no shortcuts around the learning process. 

This is not to say you’re doing a great job. Most of the full-timers on the team are likely better than you, but even the greatest programmers had to start somewhere. Keep learning, reading, looking at code, and getting code reviews, and one day you’ll look back and notice you’re a lot better than you used to be. 

In the words of the inimitable Dr. Seuss: 

And will you succeed?
Yes! You will, indeed!
(98 and 3/4 percent guaranteed.)

KID, YOU'LL MOVE MOUNTAINS!

So...
Be your name Buxbaum or Bixby or Bray
Or Mordecai Ali Van Allen O'Shea,
You're off to Great Places!
Today is your day!
Your mountain is waiting.
So...get on your way!

---

Be notified about new articles.
Next: In Praise of Memorization