As a single developer on a handful of projects, I’m a huge proponent for establishing systems and best practices, even if they don’t seem practical as an army of one.

In the past I’ve written about making sure version control is in place even if you’re the only developer on a project. It still blows my mind when I’m talking to somebody about some new project they are building and they utter the words “yeah, I probably need set up a repository for this”.

Incidentally this tends to come up when they are need in need of help and I offer to put a second set of eyes on the code for them. Nothing pisses me off more than having to unzip your code locally when I could have just browsed it on the web.

I’m nearly to the point that a lack of proper systems is enough to trigger me.

Not only is version control mandatory for anything I plan to spend more than 5 minutes on, but I also like to improve my developer quality of life as much as I possibly can.

Keeping a mindset that other people will eventually see and interact with my code is a huge contributing factor for me. If my life’s not easier, it’s gonna fucking suck for the next person.

All the test harnesses and deployment pipelines in the world still have left me feeling like there’s a blind spot. Said blind spot is in regard to code quality and as you may already know, sometimes bugs slip through, regardless of having test suites and lint detection and all of that.

Recently I’ve been adopting a self check peer review process, and I tell ya, it’s helped a ton.

Since I’m always using version control, currently favoring GitLab for a ton of reasons, I have merge requests at my disposal. For my projects lingering on GitHub, I use the pull request equivalent.

For nearly everything I work on, especially if it’s a major update, I will branch from master, write my tests and code and create a merge pull request.

Depending on the urgency of the code, I will let this merge request hang out until the next day, and then approach reviewing it as if I wasn’t the author. Having a bit of time between writing the code and reviewing it helps get me into the right mindset.

By slowing my roll, I’ve kept at least a couple of bugs from making it to production. Identifying bugs with a fresh set of eyes has paid off many times over if you ask me, even if I have had to sacrifice a bit of speed.

Not convinced?

Next time you’re patching up a bug you wrote a year ago and you’re thinking “what the hell was I even thinking here” think about this post and how many doing your own code reviews should be part of your routine.

Oh, and before you rage comment at me, I’m aware of the code review services that are out there. I love the idea, but always felt they are a bit pricier than I would be comfortable paying.

Maybe someday :)





Did you enjoy this post?

Cool if I slip into your inbox with more?
Full posts, 1-2 times per week: