Do these three things when you start a new developer job

I have worked at quite a few places now. Each time I have started a new job, I have found it difficult to get myself into "full productivity mode". With each job I started, I figured out a new thing I can do to help me reduce the on-boarding time.

In my new role, which I started in November 2019, I did some preparation. I picked three things that helped me get up to speed in the past. I would try and do these within the first two weeks of my new job.

I won't focus on the admin tasks like sorting out HR, or setting up your developer machine, or getting access to various tools your team uses. These things should be helping you become productive and valuable quickly.

Grab time with each team member

Getting to know your team members is a great way to understand who they are, how they work, and what they do.

In your first few days, you might get assigned a buddy. They will try to introduce you to the people who matter most for your role. This usually goes by in a flurry and you are likely to forget their names. When you start writing or reviewing code, you will likely be nervous about offending them. This is all normal. But you can reduce the amount of time you feel awkward by having one-to-ones first.

That's why I recommend scheduling informal one-to-ones with each team member, spread out across your first two weeks.

Goals:

• Get to know what each team member does.

• Ask them how long they have worked at the company.

• Ask them what is going well on the project.

• Ask them what can improve.

• Get to know who they are as a person (if you feel comfortable talking about that).

Grasping the situation like this helps you understand the state of the project. It also helps you to understand who the humans are around you. We're all interesting characters and no two people are the same.

This will also set you up to understand how you can be effective in the team. Perhaps there is an issue that keeps coming up that you can help to solve? Someone might ask you about a skill that you're good at and if you can help them learn it.

In my experience, I learned from three separate catch ups that we wanted to improve our testing. I shared some of my past experiences around this subject. We agreed that one of my first goals would be to help the team skill-up writing software tests.

Understand the project domain

Every new role comes with a brand new project and problem. If you are lucky, the project will be well documented, with some diagrams about how it works. There may even be a wiki describing how the problem is being solved by your software and what value it provides to users.

Even if these type of documents exist, sitting down and understanding the domain of the project is a valuable exercise.

I recommend grabbing another developer and drawing an entity relationship diagram on a whiteboard in your first few days.

Remember: you are not drawing a database structure, you are drawing a domain diagram. It should focus on the application logic. It should be understandable by non-technical members of your team. Here is an explanation if you're stuck.

Goals:

• You should use this time to ask questions. Make no assumptions about how things work.

• Understand the high-level domain of the system.

• Learn how the system achieves the user requirements.

After you have drawn a domain diagram, if one does not already exist, now is a good time to take a picture and stick it in your wiki or docs. It will be helpful for future team members.

In my experience, I spent an hour learning about one of the projects I am working on. I challenged my own assumptions and helped to understand the state of the project. I even ran it by a second team member to confirm my understanding was correct.

Complete a small programming task

Some blog posts have recommended this one point: ship some code on your first day. I guess the intention is to help you understand the procedure for shipping code. Learning how the team tests, reviews code, and ships it is definitely valuable. But I don't think it needs to be the absolute first thing you do.

I recommend taking on a small programming task in your first week.

The task should not be a bug fix. It should be a minor feature that you can finish in about a day of work (excluding environment set up time). You should be writing some tests and learning the review process by doing this.

If you can find a team member who is free, you can even try pair programming on this task.

Goals

• Understand how the software is designed.

• Understand the process for writing tests.

• Understand how you make a pull request and merge your code.

• Understand what "done" means for a feature ticket.

In my experience, I had to change a date time picker to display the last 2 years only. It was a simple enough change and I learned about the framework and how our CI/CD pipeline worked by doing it.

Remember: starting is slow

Let me wrap up by saying: starting a new job feels slow. You are likely used to high productivity from your previous job. This will feel like running through mud. That is a totally normal feeling.

Learn how your new software works.

Learn how your new team works.

Start contributing value, not just through writing code but by figuring out how you can work with your team members too.