Don’t be like blonde Gwyneth 

Or a helpful pointer for developers contributing fixes and changes to an existing code base.

Do you remember that old Gwyneth Paltrow movie Sliding Doors? Imagine that she’d been a software developer who had been asked to fix a problem with an existing software project.

Next thing you know she’s running for the train, some kid gets in her way and she misses the train but also gets the train, one of her gets a dramatically convenient hair cut, and we’re left with two Gwyneths and two insights into how things could play out.

Brunette Gwyneth investigates the defect and finds the source of the problem. She works out how to fix it and pushes a change to the code.

Her commit is small, focused, and implemented in a way that’s consistent to the style of the existing code around it.

John Hannah can look at the commit and instantly see at a glance what the bug was, and how she fixed it. They go out for a coffee and live happily ever after.

Blonde Gwyneth also investigates the defect and also finds the source of the problem. She fixes it, and decides while she’s there to improve All The Things!

Blonde Gwyneth prefers extra spaces between ){ so goes through and inserts a bunch of them. She likes to put her ‘else‘ on the same line as the curly brackets before/after them, so goes through and adjusts all the line breaks to make it the way she likes it. She thinks 100-character lines are too long, so adds a load of line breaks to make sure they all wrap nicely. She doesn’t like the logging library used in the project but wants to add some new trace and logging so uses a different approach – two ways of logging must be better than one.

Her commit is huge, touching almost every line of code in the whole project.

The result is that poor old John Hannah can’t see where the bug was, or what she actually fixed, without manually going through the diff to pick apart every change on every line to look for where the functional change is hiding.

It takes him so long that they never have time to go out for a coffee. And then she gets run over, or falls down the stairs or something. I forget how the movie ended. But you get the idea – bad things happen.

To sum up: if you’re asked to come in and work on an existing project, be like long-haired Gwyneth.

  • Coding standards are important, but your mission isn’t to persuade the world that yours is the best. Try to look for existing patterns, conventions and standards in the code you’re working in, and fit in with them. The best fixes fit in so seamlessly that someone coming to look at the code afterwards won’t see where the old code stops and your new code starts.
  • If you absolutely must refactor and reformat to suit your preferences, do it in a separate commit. Implement your fix with a comment explaining what you’ve fixed. And then push a separate change with all the reformatting in, with a comment explaining that it’s a non-functional formatting-only change, so no-one needs to spend their time wading through that diff.

Or, be like brunette Gwyneth. Because she’s awesome.

2 Responses to “Don’t be like blonde Gwyneth ”

  1. Dave Nice says:

    Yes! Completely agree. Quite annoying to have loads of small twiddles in a change set that make it hard to see the wood for the trees!

  2. Ralph says:

    Couldn’t agree more!