It's OK Not to Be Sexy

Rob Higgins // April 2014

It’s OK not to be sexy.  Now that I have your attention, and have you wondering if you accidentally stumbled onto a self-help site instead of a tech blog, let me explain.

Everyone wants to work on the “sexy” projects, exciting tasks, and newest tech. I’m here to say we, as developers, need to embrace the boring, the mundane, the proven.

Recently our company has been engaged in an ongoing discussion about testing, documentation and code review. Terms that I can guarantee made more then a few of you cringe.

It’s time we take pride in these tasks, like we take pride in our newest API technology or fresh website design.

I know from experience that it’s sometimes hard to get started writing those tests or adding new README’s. However, you get a huge sense of accomplishment once it’s done. Not unlike the spring cleanup that will be happening in houses around the country over the next few months.

Having functional and unit tests written will pay off in spades when you catch a problem before it hits production. Docs and READMEs will prove invaluable, when you or another developer need to revisit a project down the road.

I’m probably not telling you anything you don’t already know, everyone is aware these tasks are important. But when it comes time to do them, many of us are too busy, on a deadline, or say we will do it “later”. This is where taking pride in these less then exciting tasks comes into play. Be proud of your perfectly written tests. Be excited to show off your new module with complete documentation.

This is all well and good, but how do you get that momentum? Here are some of the tips that I use to remind myself and encourage good practices.

Encourage Proper Readme Usage

Create a README.txt for every module when you first setup the folder structure. Having it there almost obligates you to fill it in. In addition to this step, make it part of your commit policy to always update your README to reflect the new changes.

Utilize Code Review

Have code reviewed by co-workers. It is easy to get sloppy with your docs, tests and commits when no one else is looking. Take that option for laziness away. Not only will this encourage much cleaner code, you will learn tons from your co-workers. Everyone has their strengths and weaknesses, take advantage of your team members’ strengths to build on your weaknesses and vice-versa.

Use Test Driven Development

The tests need to be written and written well if that is the basis for your whole architecture. This can done using SimpleTest and Drupal’s functional testing approach (https://drupal.org/simpletest-tutorial-drupal7), Behat (http://bdd.alexo.it/), or even standard SimpleTest unit testing (although this approach is the most difficut to implement with a data driven model like Drupal).

Take Advantage of Git Hooks

Add a local pre-commit hook to remind yourself to have a detailed commit message and to include the issue number of the bug/tasks it applies to. This is fairly easy to implement:

  • Change working directory to the .git/hooks directory in the root of your git project.
  • Rename the pre-commit.sample file to pre-commit and make it executable.
  • Add the code to this file. This can be as simple as “echo ‘Please make sure you have a good message’ ” or much more complex such as implementing a python script and tying into the additional prepare-commit-message hook to do some formatting for you.
  • For more info on Git Hooks and some ideas see, http://git-scm.com/book/en/Customizing-Git-Git-Hooks.

Change Your Mindset

This final tip is more abstract, but is at the core of my argument. Be proud of your code not for only what it accomplishes, but what it teaches others. Imagine another developer taking over your project in 2 years. Would they be impressed? Or would they wish you had better docs? Better tests? Better comments? Take pride in all of your work. Not just the “sexy” stuff.

Filed under: