A few nights ago I was at home enjoying some quality Netflix time when my roommate Chris asked me if I was familiar with a show called “Holmes Inspection”. I said that I wasn’t, but that I was interested in checking it out. In case you’re unfamiliar, the show features Mike Holmes, an expert home inspector as he “shines a spotlight” on new homeowners facing massive repair bills and dangerous living conditions due to incompetence within the unregulated home inspection industry.
10 minutes into the first episode, Mike had already found some serious flaws. The previous owners favored an open floor plan and had a load bearing wall removed. The contractors managed to not secure the new joist and somehow installed the support beam sideways severely compromising its integrity. As a result, the entire second floor dipped so much that all the doors would stick and a ball would roll to the same spot every time. To do a job this poorly the contractors either had very little experience or they simply ignored these issues.
While watching, I couldn’t help relate the show’s premise to software development. In our industry, it’s easy to cut corners and sweep things under a rug in hopes that nobody will notice. When I first started getting serious about programming there were times where I knew code that I had written needed to be refactored or even written from scratch. At that point, though, I didn’t know where to look for help! If you find yourself in that position, there are a number of places that you can look to point you in the right direction.
A tool that I rely on regularly are code linters. If you’re not familiar with what a linter does, it’s simple! Linters will look at the code you’ve specified and will alert you of any syntax errors or infractions against that language community’s best practice guidelines. Linters for me serve as a quick check to make sure my code is clean, readable, and that I’m not making any mistakes that are easily preventable. Linters are also available for most any language you will write. Github has a great list of the most popular linters here.
Another great tool are these new slack communities that are popping up all over the place. I can actually attribute most of my learning to the company that I have kept and asking them a whole lot of questions. I’ve been spending some time in both the SlashRocket and Spec.fm slack rooms and have already learned by observing others’ conversations as well as asking questions. If you’re new to design or development, don’t be timid. Get in there and ask away!
Lastly, another step I take to ensure the code I’m writing isn’t the worst is to ask others for code reviews. If you’re apart of either the SlashRocket or Spec.fm communities and want a code review, throw your code samples into a gist, codepen, jsfiddle, or even a jsbin and send a link along with any questions about the you’ve been writing. I’ve found that the people in these communities really enjoy breaking down bits of code and talking through how to improve it. The bottom line is that by putting more eyes on to the code you’re writing you’re more than likely to glean knowledge from what others have to say.
It’s easier to write code that is brittle and easily breakable, much like it’s easier to build a house that isn’t up to code and a danger to the people that live in it. Thankfully though, with a little effort up front on our part, we can avoid the headache of having to scrap code and start over.