Survival Guide for Junior Developers
In 2015 I started my first job as a developer, after having spent five months turning my coding hobby into a profession.
The switch from doing coding bootcamp projects to working on Xeneta’s full blown SaaS app with 7 other developers forced me up a pretty steep leaning curve, which I feared I wouldn’t manage to ascend, as reading source code of similar projects scared the shit out of me.
Luckily, I did manage it. At least I have managed it so far.
So in this post I’d like to share the tips I gathered along the way, to make life slightly easier for other junior developers who’re starting their first job.
1. Accept your weaknesses and ask for help
First of all: you have a lot of holes in your knowledge and there is no reason to hide this, so swallow your pride and ask for help when you need it. If not, you’ll waste too much time banging you head against the wall.
That’s one of the reasons there are senior developers as well: to help juniors out.
I had no other choice than asking questions from the beginning off; on my first day at Xeneta I got a MacBook Pro and was told to setup my system according to the README.md file. This involved the following steps:
- create an Ubuntu instance on a Virtual Machine
- ssh into it
- clone the repos
- install packages
- get all config stuff correct
- fire up the server.
While I was familiar with some of these steps in general, I got stuck in every possible way I could. So I had to ask for help. Again and again. Else I would have wasted weeks on this setup. This trend has continued, though with less intensity as time has passed.
2. Take notes
People are usually perfectly fine with helping others out, but you should avoid asking the same question multiple times. So whenever you get help, remember to write down the solution to next time you’re in the same situation.
There are no stupid questions, but if you’ve asked the same question before, it’s a stupid one the second time you ask.
I use Trello to take notes:
3. It often sounds more complicated than it is
This is a principle is actually about coding in general: the less you know about a subject, the more complicated and scary it sounds.
Often times it’s just the terminology that’s foreign to you. Once you understand what it means in plain english, it’s not as scary after all.
Take AJAX for example. When I started coding I remember thinking that Asynchronous JavaScript And XML sounded like a very complicated procedure.
However, once I understood that AJAX is simply a technique for websites to talk with servers, it became a bit more approachable. And after I implemented for the first time, I understood what people meant when they said it was easy.
I’ve experienced this process over and over ever since.
So try to avoid feeling overwhelmed by all the stuff you don’t know. And if you do feel overwhelmed, take a deep breath and go back to step 2 (take notes). Have a Trello card where you write down concepts you don’t understand or just need to investigate further.
Then use open time slots to learn more about the concepts.
4. If it’s too complex: visualize it!
While a lot of things are easier than they sound, there are many difficult subjects in software engineering. Stuff that takes a lot of time and effort to understand. Big projects also tend to have parts of the code that are harder to understand than others.
Once a while, you might feel that something is too complicated to upload to your brains RAM, as there are simply too many intervened values, classes and functions to keep track of at once.
The best way I’ve found to tackle these situations is to visualize it with pen and paper.
Given that the brain apparently only can hold around 7 objects in memory at once, it makes sense that fleshing out the infrastructure on paper can help you reason about it.
5. Chase a lot of bugs
Finally, I’d like to encourage you to chase as many bugs as you can. Cause while it’s certainly more fun to create new features, it’s not necessarily the best way to get to know a big code base.
To do that you’ll have to chase bugs that force you to dive deep into the codebase, in parts you’ve never traversed before. This is the best way to become familiar with the architecture of the app, which is critical in order to get to a productive level.
In general, the more of the codebase you’re familiar with, the more productive you’ll be.
Secondly, this will make you understand how your team mates code, and is likely to make you realize what bad practices you’ll need to get rid of asap.
So don’t avoid bug fixes. Rather jump on them whenever you have the chance.
Good luck!
Thanks for reading! My name is Per, I’m a co-founder of Scrimba — a better way to teach and learn code.
We have a ton of intro courses for developers. If you’re looking to learn React, which I did, I’d recommend you to check out our free Learn React course, over 70.000 students have already enrolled in it.
Click the image to get to the course👇
And if you’ve read this far, I’d recommend you to check out this demo!
