I have a funny habit.

Well, I guess it’s a funny habit. I never thought of it as funny. Then people started pointing it out to me, and asking why I did such a funny thing.

A little over a hear ago, this funny habit came up during a job interview:

“It’s funny how you make pull requests for your own projects on GitHub.”

Yes. That’s right. My funny habit is that, even on solo projects (and yes, even the private ones I never publish), I create pull requests.

And I review them.

But why?

This is the question virtually everyone asks as soon as they learn that I create pull requests and review my own code.

The short answer is that most of the reasons for code review are just as relevant on solo projects as they are on team projects (mentoring being the most obvious exception). But I think it’s worth touching on some of the specific benefits of doing this on a solo project.

I’m lazy, and doubly so on solo projects

There’s something about working on a solo project, where I don’t expect others to be peering, that automatically lowers my quality standards. I expect I’m not alone in this.

I don’t always pay close attention to what files or changes I’m committing. On projects I work on infrequently, I may accidentally commit some partial change from 3 months before. I tend to be lazy with variable and function naming. I could go on and on.

By doing a final code review before merging, I allow myself the chance to catch a lot of these silly mistakes I otherwise would end up committing to the project.

It’s best practice

In most cases, best practice is best practice, regardless of the size of the team. Doctors in private practice wash their hands just as much as doctors in large institutional hospitals. Likewise, developers on solo projects and developers at Google, can both benefit from following best practices.

Even when writing code only for yourself, you can assume that you will forget the context of what you’re doing today. This means that having clean, readable code, and clean, readable git history, are just as valuable, even if the only other person who will ever read your code is a future version of you.

It develops good habits

Having two sets of processes, one for $DAY_JOB, and one for hobby projects, is probably scientifically proven (citation needed) to lead to consistency problems. By using the same practices in both arenas, it becomes a much more natural habit.

This is also a great idea if you’re new to programming, and trying to build up some industry cred, or maybe you’re trying to develop some new DevOps skills. If you have any publicly-visible hobby projects, following the practice of creating PRs and doing code review on your own code is a great way to show future employers that you know and follow best practices!

I’m convinced, but how?

Step 1: Create a pull request

There’s really no special sauce when it comes to creating a pull request. Do this exactly as you would on a team project.

Keep the changes related and relevant. One bug fix, feature, or refactor per pull request, for example. Use meaningful, descriptive commit messages.

Push the relevant changes to your version control service.

Step 2: Review it

When it comes to reviewing the code, it can help to pretend you’ve never seen the code before. Look at it through fresh, critical eyes. Look for the WTFs that would confuse you in someone else’s code (because they’ll confuse you, too, when you return to this code in 6 months).

The one thing I don’t do when reviewing my own code is provide inline comments on the PR. I just jump to my editor and make the necessary changes directly. YMMV.

Just make sure your code is of the quality you desire before merging!

Step 3: Profit!

That’s it. It’s really that simple.

I hope you’ve been challenged to begin reviewing your own code. If you’re looking for more good DevOps habits that can benefit a small or solo project, check out my post Solo DevOps.