I have an honest question for you:
“How good is your code?”
It’s a hard question to answer, even for somebody like myself that has been writing code for 20 years or so. There’s a lot of nuance into what makes ‘good code’ and as your career progresses you’ll find that a lot of it comes from a personal perspective as well.
With that in mind, this past January I took part in something that I found surprisingly enlightening, Ben Orenstein’s Code Quality Challenge. It was delivered via a daily email with each day having a new challenge for you to attempt to achieve with your daily codebase(s). The idea was that you’d spend at least 20 minutes each morning working on the day’s challenge, which would range from tooling and knowledge updates to changes to how you actually write your code.
To summarize, I found it surprisingly difficult, even if at first glance the individual challenges seem simple enough. With large, years-old repos there’s a surprising amount of things that can be made better beyond the stuff that you probably fight with every day while doing your job.
Here’s a quick summary of my favourite exercises from the challenge, if you want to explore the rest, unfortunately, there isn’t another cohort of the email delivery planned, but the exercises are on display in the forums.
Update your README
I had thought our app’s README was pretty good, but we were actually missing a few key items:
* Where to ask questions
* Who to get to review PRs
* Where to look at the output of our CI pipeline
Trim the branches / Tidy your open PRs/issues
These were two separate tips, but they’re similar enough that I feel they can be combined easily-enough.
I was surprised by how many branches that were sitting around for PRs that had been merged/closed, or simply were too old to ever consider merging (2 years). If you’re using a tool like Github it’s easy to see which branches are lingering on your master branch (on origin) but the tip itself also offers lots of techniques for cleaning up for your local copies of repos as well.
Extract a compound conditional
The article explains it better than I can do here without blatantly plagiarizing the thing. Even with code that I thought was pretty simple to understand, once I started implementing this concept I noticed code immediately started to read more clearly than it used to. Sometimes it’s the simplest ideas that have the biggest impact 🙂
Nuke TODO comments
I have to admit, this one hurt…
The title says it all, grep your codebase for TODO/FIXME etc. and either fix them then and there, remove the TODO comment, or ensure that it’s actually tracked in whatever work-for-future-you system your organization is using. I pulled the plug on this one at 20 minutes with still 400 comments left to review, but I did set a reminder to revisit the results each week.
Create a bin/setup script
What if instead of all those instructions to get started in your README, you simply had a script that did the majority of the work for you? That’s what this challenge suggests, and it’s highly worth exploring if it works for your project.
Want to try for yourself?
Unfortunately, Ben has at this time decided to not run another cohort of the challenge for the time being. I’m secretly hoping that it’ll come back in the future so that I can send all my coworkers here and unleash these learnings across all our repos.
If that doesn’t happen, the list of exercises is currently available here. Maybe set a weekday reminder for yourself to take a look through a new topic every day? I promise you’ll learn something, and your code couldn’t possibly end up in a worse state after completing even some of these challenges.
What did you think of the challenges? Do you have challenge ideas of your own? What do you do to make sure your repos are in top shape? Let me know in the comments.
