Tips for starting your first developer job

Last week a new developer started in our team. Even though it's not her first role in engineering, it made me think about my own experience as a new joiner. I had just learnt how to code a couple months before, and it was not only my first job as a developer, but also my first role in tech.

Looking back, there are some things I would have done exactly the way I did, and others that I would have done differently. So here are some tips for those of you who are about to or have just started your first developer job.

1. Take notes

This is a piece of advice I came across elsewhere on the Internet that proved to be invaluable. From the moment I walked through the doors of the company, I started to take notes and organise them carefully. I paid particular attention to the engineering workflow, architecture, acronyms, terminal commands, keyboard shortcuts, and anything else that might come in handy. This helped me a lot in getting up to speed, without having to ask my colleagues about things that they had already told me once.

Being completely new to life as a developer, I literally wrote down the steps I would have to take to get from a ticket to a merged pull request. These included things like creating a branch, starting a simulator, committing my changes, pushing my changes to the remote branch, creating a pull request, and so on. I then used these as a general guide until they became a habit, and noted down the mistakes I made along the way.

My notes have become a personal documentation tailored to my work that I still refer to now. Even though it might slow you down a bit in the beginning, it really saves you a lot of time later on, as you don't have to ask again and wait for a response. It also makes it easier for you to help other people as you might have exactly the information they need but lost in one of the many messages you exchange at work. And in some cases, you're even able to convert your notes to proper team documentation.

📝 Develop a note taking system

Since you will probably not stay at the same company forever, I would suggest using a personal account for note-taking. I have separated company-related information from learning notes, organised by different technologies (e.g. React, TypeScript, GraphQL, and so on). That way, I can easily delete any company-specific information that I might be asked to delete later, but keep my personal knowledge library.

When it comes to tools, I personally use Notion, but I might migrate my notes to GitHub at some point. GitHub can be used offline, while Notion only works online. It's also free to share your notes with as many people as you want and have them contribute to a set of notes together. Notion requires you to have a team plan for full collaboration. There's a free trial, but once this has been used up, you have to get a subscription.

2. Scrutinise the codebase

When you're just starting out, there will probably be someone who shows you the codebase and gives you a higher-level overview of how things work. Or at least that's what happened in my case. I then had some time to go over it myself, but since our codebase consisted of a monorepo, basically one huge repository shared between teams, I just skimmed through our feature. I thought I'd get to know the codebase better over time anyways.

And I did. But in hindsight, there are a lot of questions that popped up along the way, or mistakes that I made that could have been avoided by taking a proper look at the codebase. So if I were to start again, I would spend more time doing that. For example, by going over the whole flow of the product in the simulator or on the web, and really trying to understand how the data travels through the codebase and ends up where it's supposed to be.

Be critical and keep asking yourself why things are done in a particular way. This does not only help you get used to reviewing other people's code, but it also helps your team identify potential issues with the code. I was quite shy to do that in the beginning, as I often just assumed that it was somehow my problem that I couldn't understand parts of the code. But whenever I did ask, it usually turned out that that part of the code was either deprecated, superfluous or not very readable in the first place.

It also helps to take a proper look at the package.json, which usually lists all dependencies and scripts that you can use. It helps to understand which other teams interact with your feature and vice versa, and also familiarises you with some scripts that you can use in your daily work. Some of my teammates weren't aware of some of these useful scripts either, so this is also another way to be helpful.

3. Ask thoughtful questions

When I first started, I had a lot of questions. And lucky for me, I was assigned a buddy and mentor that I could ask these questions. And in most cases, she knew the answer. This was great, but I later realised some things that I could have done better.

Before I started, I asked her what tech stack the team worked with, so I could do some preparation. This question I would simply have asked earlier, as I only thought of it like two weeks before I joined when I was busy organising my move to Berlin. So I caught up on some stuff later, but it helps to read at least an intro to the technologies you've never worked with before.

When it comes to code-related questions, I initially often focused on what I wanted to do rather than what I had already done. But this would often lead to suggestions I had already tried. So now, I always tell people straight away 1) what I'm trying to do, 2) what is not working, 3) what I have already tried, and then ask my question. This saves time and makes it easier for people to help you.

When it comes to team practices or company-specific information, I could have asked more often where my buddy got the information from. Because I later realised that some of the questions I asked were already well-documented. As a new starter, I just didn't know where to find them.

4. Avoid context switching

I think one of my biggest misconceptions about life as a developer was the assumption that developers spend most of their day coding. And in some places that might be exactly what they do. But in bigger companies, you will most likely spend a significant amount of time in meetings, waiting for your build to complete, waiting for code reviews, waiting for another team to get back to you, waiting for the designer to comment, and so on.

This can lead to a lot of disruptive context switching. Things like the review process, the design handoff process and the amount of meetings you have will probably also depend on your team. But there are also some things you can do to try to avoid it.

These include:

• asking to be marked optional in non-essential meetings
• declining optional meetings, especially if they're recorded
• blocking out some focus time in your calendar
• scheduling your learning sessions at the start or end of the day
• collecting stakeholder questions and asking them at once
• only joining messaging channels you really need
• if you use Slack, turn on Do Not Disturb mode

While I realise that these suggestions might not work for everyone, they helped me reduce the amount of context switching I do. In the beginning I attended every meeting I was invited to, regardless of whether or not my input was necessary. I thought this would help me get a better overview over everything, but instead it often ended up draining me. So I hope you can be smarter than me and start prioritising sooner 🤓

5. Join or create study groups

This one I have to mention with a word of caution, because if you're anything like me, you might be tempted to join 50 study groups at the same time. Study groups really helped me stay consistent and finish bigger projects like passing the AWS Certified Developer - Associate exam. But they can also be distracting if you don't organise your time accordingly. That's why I am now only part of exactly one study group, and why I schedule my learning sessions either at the start or the end of the day.

We get a Udemy Business subscription at work. Most companies have some form of learning budget, so you'll probably also have access to some learning platform. In the beginning, I started studying some topics by myself, but I rarely finished them. All the Udemy courses I have completed so far were part of some study group. It really helps because you feel a sense of responsibility and have people who hold you accountable.

That's why I recently started my own study group. I created a learning path that I shared with others on a similar level as me and a Notion space that lists the to-dos for the week. That's also where we collect possible questions for discussion that might come up during our self-studies. We agreed on the course we want to do, and have weekly check-ins. It's not been long since we started this, but it's going well so far. So if I were to start again, I would try to form a study group from the get-go.

It's also helpful to be able to apply your knowledge straight away, so you might want to discuss your learning plan with your manager or mentor at work. That way, you can align it with the tickets you're working on. For example, shortly after starting to learn TypeScript, I converted some of our JavaScript files to TypeScript. I could then use the issues I encountered as a basis for further learning.

6. Record your achievements

This is probably one of the most important tips here. It's a suggestion that my manager made when I first started. And I'm very glad that I took it more seriously than he had initially meant. Because it did not only make it easier for my manager to make a case for me passing probation, but it also helped me feel less like a fraud. I will probably write a separate article on imposter syndrome at some point, but either way, make sure to record your achievements.

There is just so much you do in your daily life that you simply forget. And at one point you might be standing there, looking back and wonder what you actually did. That has happened to me a lot since I first started working as a developer about a year ago. There are moments where you might doubt your skills and feel like you're not learning fast enough. Or moments where it seems like everyone else knows so much more than you. And that's when your achievement sheet can remind you of all the things you've done and learnt, and all the progress you've made since walking through the door.

In my case, I just opened a Google doc that I called "my achievements" and noted down every ticket I worked on and what I learnt in a particular month. While quantity is not as important as quality, I also recorded the number of the ticket I was working on, as it felt like a personal milestone to me. In the first six months, I would also write a short summary every two months. I organised my achievements in reverse chronological order with the most recent work on top.

Recording my achievements is actually something I wish I had done much sooner in my career. It only takes a couple minutes a day to write some bullet points of what you did and what you learnt. But you can use it well beyond your current job. It does not only serve as a means to motivate and encourage yourself, but also helps to refine your CV, to talk about the things you've done at interviews, and to make a case for yourself more generally. And it helps your manager too. Because a good manager wants you to succeed, but is often preoccupied with their own work and career.

So it's not only a means of advocating for yourself, but also makes it easier for others to do so. Depending on what you've done, you can also share some achievements publicly to inspire others at some point, as I have seen some people do before.

And that's it.

Those are the tips I have for people who are about to or have just started their first developer job. I hope that they help at least some of you 😊 And finally, good luck and much success to those of you just starting out. You can do it 💪🏼

_{Cover image by David Travis on Unsplash}