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 🙂
