You’ve got the job – now what?

You’ve spent the past 4 – 6 months studying a very carefully curated curriculum: first you learned how to ‘hello world’ in Ruby, then you learned how to template that message in Rails, finally you learned how to make the letters change colors when you clicked on them using JavaScript.

You’ve learned so much in the past few months that you’ve managed to trick a company into paying you a crazy amount of money each week because they believe you can take their product to the next level.

You show up on day 1, go through a brief orientation, and install Atom. Now what? You’ve only ever worked on small codebases where you were intimately familiar with every line of code. Your new company’s project is thousands of times bigger and growing each day. It feels like a new pull request is merged into the repository every time you reload the page. How are you going to become familiar with something this fluid?

Read the docs

This is usually a great place to start – engineers will usually hide useful information in here like ‘how to run tests’ and ‘API documentation’. It might be in a markdown file, it might be in the Github Wiki, it might be on a third party site. Find out where the docs are and read them.

What? You just talked to the tech lead and you’ve been informed the docs haven’t been well-written or maintained? Well…

Write the docs

I know it feels like you’re trying to write a calculus textbook when you’ve finished third grade math, but you’d be amazed how much you can contribute during your cursory look at the project. The maintainers have been working on the codebase for much longer, and probably assume a non-trivial understanding of the code when writing documentation. As an outsider, you bring a new perspective to the project – ask about the unclear parts, and update the docs!

Did you have to install any programs to make setup easier? Did it take you thirty minutes and a conversation with an engineer to figure out an obscure command to build the project? Get it all into the docs!

While you’re reading the source code, if an API looks extremely complicated, trace through its calls and try to write down (or diagram!) what is happening at each step. This will be very valuable if anyone needs to refactor this logic in the future.

Next time someone new joins the team, give them your new docs and watch how fast they ramp up!

Run the tests

Tests should give you a good idea of what each module was designed to do. Pay attention to expected inputs and outputs of the tests. Look at the mocked data for any external calls to better understand the contract between clients.

Refactor

Remember that extremely complicated API you documented in the previous step? Think about if there is an opportunity to make it more obvious. Would it make more sense if parts of the method were broken out into their own reusable methods? Would the code be more clean if it used promises instead of callbacks?

Start small

In the task backlog, pick up projects that are relatively independent of the rest of the code. This makes debugging much easier when you aren’t confident in your knowledge of how the system works as a whole. As you get comfortable with the codebase, you will naturally get a better grasp on the entire codebase.

Leave a Reply

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