You know you enjoy coding, but what’s it like to do it for a job? What can you expect in your first week?

I can’t imagine my first week at a new job. Do you start coding right away? What if they use a language/framework that you haven’t learned? How do you get up to speed with the codebase, and know what the priorities are? Is it easy to get into the team? Can you just… open your editor and start coding? What if you get something horribly wrong and break everything?

I worked in a coding bootcamp for 2 years, and I heard similar questions from a lot of students. They knew they loved coding, and loved what they were doing on a daily basis at bootcamp — but they wanted to know what it felt like to go into an actual job.

In this post, I’ll use examples of what I did during the first few days in my most recent role and try to give you an idea of ​​what you can expect.

I am working as full stack developer in a small company. There are four developers and one CTO in the engineering team (including me). We also work closely with a Product Owner, who is one of the founders. I went with a few years of coding experience.

All services are on AWS and we use NodeJS and Ruby.

Day 1: Mostly Setup
I reached office at 9 am. A shiny new MacBook Pro was waiting for me on my desk, complete with adapters and two screens. The dev team took me out for breakfast at a cafe nearby, and when we came back I sat down and started setting up my machine.

Since I’ve set up countless dev environments before working at Coding Bootcamp, it was pretty straightforward and didn’t take me much time. However, I only installed the Ruby/Rails environment on my laptop once, so that part took me a bit longer.

I was provided with an A4 sheet listing the requirements, version numbers, and so on, which I made sure to follow carefully. I was given access to various sites like Bitbucket, a password manager, AWS and GitLab, and set up my SSH keys on my new machine.

Before lunch, I went for a chat with the CTO and we talked in detail about the product, the architecture, and the goals and priorities of the dev team for the near future.

After lunch, I cloned some of the services that make up the application and began to familiarize myself with the codebase. Luckily for me, I joined the team at a time when some fresh, new parts of the service were under development, meaning I didn’t have much code to speed up.

For the last few hours of the day, I sat with one of the senior developers while he implemented a feature. We used this as an opportunity to guide me through that part of the app, explaining why things were done in specific ways, the parts that caused problems, and aspects that may change in the future.

Day 2: Testing
I was given the task of testing some functions for the app in a repo. Giving new hires to write tests is a great way to introduce them to the codebase and some of the logic of the application.

I spent a lot of time reading the code, figuring out how it all worked together, and seeing if I could follow the flow of the logic. I was interested in the conventions the team chose, the way the code was divided, and the stylistic choices. The tests weren’t hard to write, but I’m always really cautious to make my first mark on a codebase I haven’t worked on before!

I didn’t want my work to progress, so I tried to look at and absorb the code style that was currently being used. To some extent, good practices like linings help a lot, but there are only general architectural and stylistic choices that linings cannot help you with.

A small challenge I had was getting used to the Git workflows the team used. Each team has its own way of doing things: some teams merge, some teams rebase, some teams squash and others don’t, some follow this popular workflow, and others just master villi. Nili pushes in. In addition, there are conventions of commit messages and descriptions, review processes, and so on, to be correct.

Overall, there’s a lot of non-obvious “this is how we do things” stuff to take in. After going through the process a couple of times, correcting your mistakes and asking questions, it’s second nature now.

All the time I was writing notes in a notebook and kept code snippets in an application called Bear. There was a lot in it – how to do things, preferred processes for the team, things I hadn’t done before, and new languages ​​and frameworks to learn.

I really needed to be proactive in noting what I was learning. I made it a point at the end or beginning of every day to review my notes, add additional explanations to things I wrote down in a hurry, and research material I didn’t fully understand.

Leave a Reply

Your email address will not be published. Required fields are marked *