Tips for your first few weeks as a junior developer

Note — this is a follow-on article from “What it takes to stand out as a new Computer Science graduate”.

You’ve got the new job! Congratulations!!! Now it’s time to put your skills and knowledge to work in the real world. I’ve seen a fair number of junior developers come through our team at Education Perfect, many of whom are now senior devs, fantastic coders and some of my most trusted friends. Everyone has their own journey, but there are a few patterns emerge, and some recommendations I can give to get you off to the best possible start in your new workplace.

Come ready to Learn

• You’ve got a wonderful opportunity to observe how developers who have been doing this for a long while go about their trade. Soak it up!

Don’t be afraid to ask lots of questions

• Have a pad of paper (or a google doc) handy to write questions down. It’s OK to have a lot of questions, and it’s great to pepper your mentor with them. However, remember that your mentor will also have his/her own work to get on with, so rather than interrupt them every few minutes with another question, save them up for your scheduled catchups (which should hopefully be at least daily for the first few weeks).

Contribute wherever you can

• Remember that your team is investing a lot of time and effort into mentoring you in these first few months, so jump at any opportunities that come up to do something useful for them.

Little things like grabbing the team’s coffee orders can generate a lot of goodwill within your new team

Seek out the bigger picture

• Always try and understand the bigger picture of the work you’re doing. Hopefully your mentor will provide you with this additional context (often after the meetings where things are discussed), but if they don’t and you’re unsure then ask them. This will be helpful for your learning, but also prevents you ending up down rabbit holes or ending up with a whole lot of unintended consequences from the code you’ve added/changed.

Understand your users

• Jump at any opportunities to interact with your users (or if not, at least with your product team who hopefully understands them!). This may be a little scary, but remember that they’re just human beings too. This might involve going out and observing user-testing sessions or directly interacting with customers, but it can also be as simple as reaching out via email to a user with a request to better understand what they’re trying to achieve. The best software developers show empathy towards their users and build solutions which understand their needs and solve their problems. It helps you to contextualise the work that you’re doing, and also makes it that much more meaningful. Even when you’re deep in the bowels of a technical challenge, understanding your users will allow you to make pragmatic choices about where to focus your efforts and will allow you get things done faster as a result.

Know what’s expected of you

• Make sure you understand what’s expected of you in the first few months. Not just your immediate roles and responsibilities (though these are also important to understand), but how your team would like to see you develop in these first few months. Remember that the person that they hired is not “you right now”, but actually “you in 6 months time”, with more experience and knowledge of working with their systems. Your job is to get from A to B as fast as possible and start providing value, so it’s important that you understand what B looks like! What will you need to know by then? What skills or competencies will you need to demonstrate? If you know what you’re aiming for you can focus your attention on getting there.
• This is also a great chance to ask about the resources and support that the business can provide to help you along this path.

Getting Unstuck

• Sometimes you’re going to get stuck and not know what to do. This is normal. There’s an interesting balance here between taking the initiative and searching through documentation, etc. to try and find the answer vs. asking your mentor for advice. I’ve seen junior developers at both ends of this spectrum. One of them would spend days working on a piece of code before asking for help, when we could have set him right in literally a few minutes. Another one would freeze when they hit the most minor of impediments and we wished he would take just a little more initiative in trying to solve their own problems. I’d suggest asking your mentor what he/she would prefer you do when you get stuck. If you can leave that particular part of the code alone and keep moving with something else in the mean time then that’s probably optimal. Otherwise, send them an asynchronous message (Slack, etc.) asking for help, and in the mean time start to investigate the problem yourself.

They’re going to do things differently

• There is no “right” way to build software, but for the next few months you’re going to learn the way they do it in this particular company. Often in life, we need systems and standardisation to be able to cooperate effectively, and exactly what these rules or systems say is often less important than the coherence they achieve when everyone sticks to them. As an example, look at driving. There’s nothing inherently more “correct” about driving on the right hand side or left hand side of the road, but it’s really important that we all agree on which side of the road we’re driving on, otherwise there would be chaos! Development processes are a bit like this too. Most sets of processes have pros and cons, and what’s most important is that the team members all understands their process and can work effectively within it. The processes at your company might be quite different to what you learned during your university course. Use this as an opportunity to see the pros and cons of this style compared to what you’re used to. By all means share your thoughts about these differences with your mentor — they’ll probably find your ideas really interesting. At the same time, accept that for the time being your team’s systems are unlikely to radically change and you’ll need to align to them. With time, experience and trust you can advocate for system changes and improvements. Expect that this is going to take a while though.

It’s too much!

• Expect to feel way out of your depth when you start looking through the code-base. Operational systems are often big and complex, and they’ve evolved organically over a period of time to be the way they are today. You’ll find some things which don’t make sense if you were building the code from scratch, but made sense however many years ago that part of the system was originally written. Despite peoples’ best intentions, you’ll find parts of the system with code that is hard to read and there is sparse (if any) documentation. And in a big system, there’s simply a tonne of code. It’s going to take a number of months to be comfortable in the environment, and with a big enough system you may never know the ins-and-outs of the whole thing (and that’s OK!).

Sometimes you’re going to have nothing to do

• You may well have times with nothing to do or be assigned “busy-work”. Don’t worry — this doesn’t mean that your team doesn’t like you. Your team will be under all sorts of pressures, and sometimes this will mean that you’ll get a bit sidelined from time to time. Use this time to explore the product they’re working on and get a better feeling for what they’re trying to achieve. You could also have a look around the code base and get a better feel for how it’s put together. Finally, it might be worth having some relevant research or reading that you could be doing in your down time. Is there a new coding language that you need to be learning for the company? Do they use development frameworks you haven’t yet come across? Are there coding patterns that you’ve seen that you haven’t come across before? All of these can make for interesting reading and research, and shows to your team that you’re engaged and interested even when there’s not an immediate next step for you.

Make friends

• You’re going to be spending a lot of time with the people in your office over the next 12 or more months, so you may as well get to know them!
• Be a little brave in the lunchroom and start up conversations with your team members. Be interested in them as people rather than just in their work-roles. They’ll have hobbies and interests, families that they care deeply about, and other parts to their lives which they probably won’t get to express much of in their work days.

• Say yes to any invitations for social engagements with your team members. Different teams have different dynamics about how much time they spend together outside of work, but most will have some sort of contact point (even if it’s just going for lunch together some days of the week). You don’t need to do any activities that you feel uncomfortable about (e.g. I don’t drink alcohol), but you can often find intermediate solutions (I’ll still go along to an evening drinks engagement, even if I only stay for the first hour and drink a sparkling water).