How to Ace Your First Code Change at Your New Job
Tags: Developer, Software Engineering, Software, Software Development, Code Review

How to Ace Your First Code Change at Your New Job CodeRevGuru Follow Jun 30 · 4 min read

Photo by Charles Deluvio on Unsplash

Meet CodeRev, a career focused software developer that wants to take over the world.

CodeRev studied hard. CodeRev leetcoded hard. CodeRev did tons of side projects. CodeRev even learned React on his spare time.

CodeRev passed the technical interview and successfully got a developer job at a new company. Congrats to CodeRev!

CodeRev got his first issue assigned. CodeRev rubbed his hands together and wanted to make a good impression with his first pull request / code review and banged out the code in a jiffy. Submit pull request. Boom. Mike drop.

But then…

CodeRev got 40 comments on the PR. Turns out the styling is all messed up. Use spaces! CodeRev missed an edge case in his unit test. CodeRev had a spelling error in a variable name. Actually, CodeRev’s PR simply doesn’t build at all.

CodeRev reads through the comments with horror. He’s done. His career is over at this company. Better find a new job.

Photo by Jackson Simmer on Unsplash

Don’t be like CodeRev. Here are some common mistakes to avoid on your first PR at your new job.

Breaking the Build

Do not break the build. Do not check in broken code. Do not ask people to review broken code. Do not assume other people will checkout out your changes locally and build the code. Do not assume.

Common gotchas include not rebasing / merging the latest changes and build your changes on top, not running checkstyle / jslint / whatever linter tools the existing codebase uses, and not running all the legacy unit tests. Yes, all of those tests.

Run the build locally. Run all tests. Make sure checkstyle passes. Don’t break the build and don’t waste other’s time.

Not Actually Solving the Problem

First and foremost, your code needs to be correct. That is, it must solve the problem that you’re trying to solve. Look through the JIRA issue carefully. Ask the issue creators for clarifying questions. Identify for all potential edge cases. For example, can the input ever be invalid or null? What should the UI display if the backend returns 400? Should option A actually be enabled if option B is already involved?

Ask lots of questions. Ask your colleagues for help. Ask the PM before you become enemies. Ask developers that worked on the same code base. Assume nothing. Write good tests. Do the right thing.

Not Respecting Convention / Existing Styles and Patterns

Yes, you are ambitious and you want to do the right thing. You want to drive change and write beautiful code with elegant abstractions. Those are all good things, but there is a place and time for everything.

If your first issue assigned is something like changing the color of this banner, don’t rewrite all the CSS files with LESS cause it’s cooler and much easier to read. The original dev probably used CSS because LESS wasn’t a thing yet. Other developers on your team probably only know plain CSS. The original dev is not less hip than you, the code base is simply an artifact of the times.

Respect what came before. People do things for a reason. Try to follow what is established in the code base. If the existing stuff is hot garbage, bring up refactoring as a separate issue. Communicate with your teammates. Communicate.

Not Proof-Reading Your Code Change

You want to bang out the PR ASAP to show that you’re an elite coder with legendary productivity to establish clout. But then your PR is plagued with copy-paste errors, typos, weird indentations, just downright messy.

Not proof-reading / double-checking your changes express to others that you do not value their time. You are taking away precious focus time from other developers by not being careful about your code.

Honest mistakes are OK, but double, triple check your changes to avoid obvious errors. A good way to attack this is to use a code review checklist like this.

Want One-on-One Help for Your First PR?

At coderevguru.io we believe in creating a safe space for developer to ask for help. From one-on-one Slack sessions for general questions to individual code feedbacks with actionable items, coderevguru.io will help you get to the next level. Reach out to us for help today at coderevguru@gmail.com.