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 six different internships over the course of my undergraduate years, which means I’ve onboarded to a new codebase six different times, used six different tech and DevOps stacks, went through six different types of documentation, and interfaced with six 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 the important things I learned from my junior developer experiences.
Don’t go straight to Stack Overflow.
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>”.
Learn the standard libraries.
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.
Put away your phone.
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.
Figure out how to unblock yourself.
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.
- Internal documentation. This includes internally-maintained wikis like Confluence, READMEs, and Q&A sites.
- External documentation. This includes publicly-facing library documentation, tutorials, and RFCs.
- Codebases, both internal and external. This includes GitHub as well as your company’s codebase.
- Chat logs. Your team probably uses a chat app like IRC, Slack, or Microsoft Teams and it almost certainly supports search. You also may be able to search your company’s email archives.
- Issue managers like JIRA or Asana often have tickets or comments on tickets that deal with problems you might face. Seeing who assigns or is assigned to tickets can also be helpful in figuring out who you can ask for help.
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.
Figure out when to ask for help.
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.
- Decide what your threshold is for asking for help. It could be 45 minutes, three hours, or a day – it depends on you, your skill level, your deadline, the company culture, how willing to help the people around you are, and your level of desperation. But once you hit that threshold, you need to stop trying, swallow your pride, and ask someone for help.
- Document what you’ve tried already and why it didn’t work, so that the person who you ask for help can see that you’ve tried to solve the problem first, and so that they won’t try those to use those the same approaches when trying to fix the problem.
- If you have a lot of questions and they’re not absolute blockers, save them for later and then ask them all at once. This way, you won’t be constantly interrupting people’s work – you can ask them if they can sit down with you for an hour, and then ask them all of your questions at once. Something that helps with this is working on more than one task at a time; this way, if you’re stuck on one or have a blocking question you can work on the other while you think about it.
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.
Keep track of what’s going on in the industry.
There are a couple of reasons why this is important.
- It will lead you to articles and opinions of other engineers as well as industry leaders. Reading is a superpower because it lets you see through others’ eyes, and reading what people in the industry have spent thirty years discovering will prevent you from spending thirty years discovering the same thing. It also gives you perspective on what people in different roles on a team and in a company want from you, the challenges that they face in achieving what they want to achieve, and what you can do to make their lives easier.
- You’ll become knowledgable about new libraries, technologies, and services. This is a great way to discover new tools you can use to approach a new functionality or project. You’ll also find out about new versions and capabilities of the tools you already use.
- Hate writing unit tests? Surprise – so does everyone else! You’ll find it’s fun and relieving to share your likes, dislikes, satisfactions, and frustrations with others in the fraternity of software developers.
- It will introduce you new ideas. The work of tech visionaries like Joel Spolsky and Rands in Repose are often bandied around and quoted, and it’s interesting and valuable to go through what they’ve written.
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.
Stop being insecure.
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!
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!
Reprinted with permission.