You’re doing it wrong if…

2 minute read

This post was originally posted on the Cevo Australia website

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 write.

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.