Tips and Tricks - Starting a new [Thing]

Originally posted on my website, jnielson.com

Hi there! As I mentioned in my last post that I was changing jobs, I've recently had the pleasure of starting in on some new projects at a new job. It's been a rollercoaster trying to absorb as much information as possible while also trying to contribute to the forward progress of the company and the projects that I get to work on. It's really easy when starting on a new [Thing], be that a project, employment opportunity, or something entirely different, to be discouraged and overwhelmed at the sheer amount of information you need to gather. In this post I'll outline some of the thoughts I've had as I have dove head first into my new job where I've worked on a major project and at least 3 smaller projects in my first two weeks.

The high-level thoughts:

find someone you can ask all your questions to

Don't be afraid to clarify processes

Put up half-finished work to get feedback

See if you can setup some regular pair programming

Find something you can do during work to connect with people

Let's dive in!

The first thing I've appreciated with this new employment opportunity has been the focus on helping me become familiar with the projects and productive as quickly as possible. It's not fun to sit for a couple hours not knowing how to move forward on a large project, since even the smallest task can be daunting in a large codebase. The major project I'm working on has had a few devs working on it for a while now, which means that it's super quick for them to do the small task I was assigned... but if they do it I can't learn nearly as well! So, I'm grateful that my company has a structure where there's a lead developer (lead dev) who has it as a part of their job description to directly support other developers, especially the new ones. Sometimes this means that the lead dev spends way more time supporting that new person on a task then it would take for them to do it. A quick example...

This screenshot is actually from a w3schools example since I was working on an internal project

Tale of the dropdown search field

One of the first small tasks I worked on was updating a dropdown search field to automatically focus the search box when it is opened. While my lead dev could have finished this task in probably 30 seconds, he assigned it to me knowing it would take me way longer than that to finish. As is pretty typical when working on a project for the first while, it can take a good amount of extra time to track down where things are happening and how to adjust existing code (that was written by someone else) to accomplish the task at hand. So, in this example I poked around on the running site (locally) to figure out where the code for this dropdown search field lived... and eventually found it. While I could have asked my lead what file to make the change in, I've found it super helpful since then to have spent some time digging around in the project, as it built up some context on where the various pieces are coming from and how they fit together.

Things I've done

Now let's focus on some things that I've tried to do as "the new person" to have more fun and be more useful and productive! The first, and in my opinion, most important is I've tried to find a fun way to be involved and connect with the people at work. Connecting with people has a number of benefits, like making it more enjoyable to be at work even if work things are hard. The way that I've found most fun to connect with the people in my office has been foosball! It's fantastic, especially since there was already a decently active group before I started making it easier to jump in and meet people. I've also tried to be involved in the smaller lunch group that hangs around the office and chills. Today a part of that group played Super Smash Bros, which I joined and had a blast! Basically, find things to do with people, in my case one on one or in small groups to get to know them.

Looping back to the list

Of the high-level thoughts I listed above I've really only talked about the first and last ones. The middle ones are a bit harder at least for me since they involve leaving my comfort zone and admitting that I don't know everything.

For example, on my first day I was told what the basic outline of the dev process was and that it applied to most projects. A few days later, I was working on a project doing what I thought was the process and trying to follow my advice of opening a PR early with half-finished work, and then noticed... the PR from another person that was up was to an entirely different branch! So, I quickly reached out to my lead dev sharing the process that I thought I was following and asked if it applied to this project. He responded promptly (thankfully) and filled in the gaps, since this particular project has a stricter process than most of the other ones at the company due to a large upcoming release that I was helping with. This experience helped me realize how important it is to clarify things, especially when jumping between different projects.

One of my favorite things about this position has been the scheduled, Monday through Thursday, hour long pair programming block with my lead dev. It's super useful! It's a time that I can ask pretty much any question (related to work) that I've run into since the last one, if I didn't get to catch him more quickly. It's also a time where I know I have their full attention, since they don't even bring their laptop in. This time has also been critical in orienting myself with the various tasks I've worked on in these first two weeks, helping me to make progress faster by leaning on his experience with the codebase.

What do you do?

These are some of the things that I've noticed have helped a ton during these first two weeks at my new job. I'd love to hear about what you've done! Feel free to reach out on twitter or use the comments below.