You're doing it wrong if...

When you have eliminated what's wrong, whatever remains, however improbable, must be right.

We are all looking to learn from our failures and make things better, but sometimes it better to communicate what is right by eliminating what is wrong.

“When you have eliminated what’s wrong, whatever remains, however improbable, must be right”.

Steve Mactaggart

I’ve been around for a while, worked through different teams, across different industries and companies.
Over time I have learnt a lot of lessons, some the easy way, most the hard way.

While the failures have all been different, their learnings have regularly overlapped and now form a set of practices that guide me on a daily basis. I’ve tried lots of different ways to collect these patterns, and for a long time I was focused on passing on what the best practices were. But they never seemed to fit.

Then I realised, I was doing it wrong.

Instead of trying to describe what you should do, I should really just have been listing what not to do.

Like Sherlock Holmes said

“When you have eliminated the impossible, whatever remains, however improbable, must be the truth”.

But in this case it’s more like

“When you have eliminated what’s wrong, whatever remains, however improbable, must be right”.

It’s can be really liberating to take this approach, by defining what not to do you don’t have to be right, you only have to not be wrong. It might sound counter intuitive, but I think you’ll find that it’s much easier to exclude the things that have caused pain than it is to try and encode how to do it right.

By not saying what to do, you can guide your teams away from bad habits, while still enabling them space to own their own destiny and foster innovation.

So here is my list, these are some of the core rules that I use to help differentiate between what we should and shouldn’t be doing.

You’re doing it wrong if…

  1. the first time you are doing it is in production
  2. your code is not in version control
  3. there are no tests for the code you just wrote
  4. there is no documentation that explains what you’re doing and why
  5. you are not concerned about how the change will get to production
  6. you are logging onto a server to make a manual change
  7. you think security and privacy are features that can be prioritised
  8. you need to give someone your password
  9. you feel the need to git push -f
  10. you are not having fun!

Tweet your list

Would these work for you? Have you got your own rules to live by?

Tweet us your items, use the hashtag #YDIWI to join the discussion.

Contact us

We will get back to you within 24 hours.