The Blog

Code Reviews

I started my current freelance role 6 years ago. I created an intranet, which I have been expanding and maintaining mostly by myself. Recently, a new senior developer has joined the team, as a permanent member of staff. During the induction process we discussed how we should work together, and decided early on that code reviews would be useful. They would enable me to check that he's using the existing (well, legacy to him) code in the right way, and secondly to ensure the code he produces is of suitable quality.

The notion of suitable quality is somewhat subjective, so we talked at length how we could make it more objective. There are horror stories about code reviews causing tensions between coders, and we wanted to avoid starring in our own. Having objective ways to assess the code under review would help.

We also agreed that the code was under review, not the coder, so any perceived criticism need not be taken personally.

The objective criteria we came up with are:

  • The code should compile and run
  • The unit tests should all pass
  • The code should implement the specification
  • The coding standards have been adhered to
  • The code is SOLID

Being objective, this allows us to write code in our own personal style; after all, there are many ways to solve the same problem. So long as the criteria are met, the code is acceptable.

I decided that my code should be reviewed too. For years I've been working mostly alone with no review process, and it would do the codebase and me some good. This meant a bit of source control reconfiguration; I used to code on the main github repo, but now I have a fork that I develop on, and submit pull requests to the main repo for review. The github pull request and code review process is really good (with the possible exception of a feisty red cross icon against any comment).

Well, so far it's going well. As we know our code will be reviewed, we run through the checklist before submitting the pull request, so the code is already improved before the review starts. There have been no major infractions: most of the requested changes have been typos, suggested renamings, the odd tabs / spaces inconsistency. There was one small but clear bug; I think a less than that should have been a greater than or something like that; a code review is a much cheaper place to find it than on the live site.

The best moments so far though, have been when noticing small code smells. This has led to a couple of good conversations discussing what the problem might be (they weren't immediately obvious), and suggesting possible refactorings. After a bit of recoding, the resubmitted code was leaner, more SOLID, more readable, and just plainly better. If it wasn't obvious beforehand, it certainly was afterwards.

In all, I'm really pleased with how the code reviews have been going. I feel more confident about the codebase, and my coding skills. I've learnt a couple of new things from reading every line of someone else's code too, which is a side-effect I hadn't anticipated.

Measuring Software Development Progress

After recently having a brief discussion about progress, I thought I would try to write a list of all the ways people have tried to measure how a project is going.

  1. Lines of code written
  2. Number of bugs fixed
  3. Man hours spent
  4. Number of deadlines hit
  5. Deadline overrun
  6. Elapsed time
  7. Story points completed
  8. Velocity
  9. Burn down rate
  10. Money earnt (or saved) by the users
  11. Time saved by the users
  12. Bugs introduced
  13. Uptime
  14. User complaints
  15. Scope creep
  16. Working software

I never knew that was there

In Visual Studio, I use Ctrl+F12 to go to the implementation of a method. Just now, I accidentally pressed Alt+F12 and what happened next blew my mind. An inner editor window opened under the line of code I was on, with the code for the method I wanted to see visible.

I have no idea what this feature is called, or whether it is from Visual Studio or Resharper, but I'll be using it a lot, especially with test-driven development.

Update: I just googled it, and it's called Peek Definition.



Inner Editor

Being more organised

I was talking to a self-confessed disorganised person recently. I used to say I was disorganised, but I've put so many systems in place over the years to counter this, I might well now be considered organised. Anyway, here are a few of my systems, for his benefit, and anyone else.

Phoning myself

If I'm at work, and suddenly remember something I have to do at home, I'll phone my home landline and leave myself a message on the answer machine. When I get home, I'll see there's a message, and play it. "Hi Simon, it's Simon. Don't forget to ..."

Likewise, when I'm just about to drift off to sleep, I often remember something to do at work, so I'll phone my work voicemail.


If I have to remember to take something with me when I go out later, or in the morning. I leave it on the front doormat. When it's time to go out, I would have to move it to open the door, which reminds me it needs to come too.

Homes for things

Everything should have a home. Whenever I finish using something, I put it back in it's home. It doesn't matter how random or strange the home is, so long as it lives there. My hammer lives in the bottom of the coat cupboard, for example. It's always there, unless I'm using it, and then it goes back.

Keys, phone, wallet

The holy trinity of misplaced objects. Again, these need homes. Two homes. One home for when I'm out and about, and the other for when I'm in my home. The first home is in my trousers. Phone and wallet in my front left pocket, keys and coins in my front right. They will always be there, unless I'm using them, and then they go back. They don't go in my jacket pocket, or in a back pocket, or on the table at the pub, or anything else. They stay in their pocket.

At home, when I go to bed, I put my phone on to charge, next to my bed, as I use it as an alarm clock. When I get dressed, I put it in my trousers. My keys and wallet live in my trousers overnight. If I want to wear different trousers, I transfer everything across before putting them on.

It sounds like a bit of hassle, and perhaps it takes a while to get used to, but once it becomes habit, it doesn't require any thought, and you'll always know where they are.

Camera phone as a notepad

I realised a while ago that taking notes isn't always practical, and taking photos of things is a super quick way to remember things. I use it to take photos of books that I might want to buy in the future, notes that have been scribbled on a bit of paper that will probably get lost, timetables and so on.

Turning around before walking out

When leaving a café or restaurant, I turn round for a last look at the table before walking out, to make sure I've not left anything on or under the table, and not left my laptop charger plugged in. It's now a habit.

Pre-packed laptop bag

I make sure that I have anything I could need in my laptop backpack, and they live there until used, and go back: mains adapter, phone charger, mouse, notepad, pen, business cards, deodourant and penknife. Whenever I go out with it, I know all I need to do is put my laptop in the bag, and I'm ready to go. I've had to buy a spare charger and mouse, but it's worth it to save the hassle of forgetting them.

Calendar and diary

This used to be such a problem with my wife and I double-booking things, but we've finally solved it using a shared Google calendar, synchronised on our phones. Don't book anything until you've checked the calendar on your phone.


I use Dropbox, but there are other things that are just as good. The important thing is that it is automatic. My phone automatically uploads photos and my computer files are saved in dropbox folders by default. Once it has been set up, it doesn't need thinking about.

On the way home could you just ...

When I used to commute by car, and had something to do on the way home, I'd often arrive home having forgotten to do it. The reason was driving on autopilot. I solved this by working out exactly where I needed to change my normal route - the particular junction. Before setting off home, I'd visualise it, and when I came up to it, I'd remember to turn off. Once I'd turned off, I wasn't on my usual route, so I wouldn't forget any more.


Continuous JavaScript Testing

Being used to NCrunch continuously running my unit tests as I type, I was looking for a similar solution for my JavaScript tests. I'm using Jasmine, which runs from a single HTML page. When I want to re-run the tests, I manually refresh the page in the browser.

Obviously this is a PITN, so by adding a meta tag I kept from the 90s, I've got my page refreshing every 2 seconds and running the tests.

<meta http-equiv="refresh" content="2">