We as an industry are inherently lazy. We tend to step back and read up on what are the “best” ways of implementing design or development. This is the safest thing to do and in some cases in some environments this is the only thing you can do, because if you don’t follow the best ways of doing something you may fail and this could prove costly to the customer (now the customer may be a client you are working for or the business who employs you). Most developers write software with the stabilizers on, now is the time to take those stabilizers off and start to cycle the bike by yourself, experiment, see how you get on.
If you look at the Dreyfus model of skills acquisition, were you have various levels from Novice to Expert, one particular level sticks out; proficient.
This is where most developers will find themselves, a proficient developer is one that writes software following the best practices and delivers value to the customer. But, how does one become an Expert? I attended a talk by the brilliant Doc Norton on the Experimentation Mind-set at the NDC in London last year (in fact I blogged about it and other talks here), Doc spoke about this very topic, in that if we look at best practices as leading practices instead, then we are encouraged to seek better ways of implementing something, we should consider design patterns as leading patterns and come up with new patterns, we should consider micro-services as one of leading practices and evolve this to better ways of architecting software. We need to stop following the crowd and start leading it, become the expert, so people follow us.
But going back to my point on the costs of failure to the customer; we need to encourage a culture of “failure as an option”, this is something that Google employ, and they encourage experimentation. Obviously, failure should not be repeatable and you need to know when it’s ok to stop. Going back to my previous post on treating problems as opportunities to learn, you could treat the “failure is ok” to the customer as an opportunity to develop the trust and communication relationship of why this can be ok and the benefits it can bring. It also encourages a loosely entrepreneurial mind-set, where you may fail the first couple of times when you try something different, something you think is better, but when you succeed, the pay-out can be huge.
But don’t be afraid to try. A few years ago, there was this thing called Flash, if you are not sure what it is, internet historians I’m sure will be able to help, or head down to your local library and I’m sure there are some dusty books on Flash. Ok, you may have guessed, I’m not a Flash fan, but, I was a Flash developer at one point in my life. At the time, it seemed like the best way to design a website, I was lazy and followed that trend, it didn’t take too long in the internet evolution before developers realised that you could do the same things with JavaScript and CSS, but someone made that transition and others followed. This was where I fell into the trap of the seemingly best way of implementing something, but I had to stop, drop and re-learn.
So it’s time to stop following best practices and start treating them as leading practices.
Thanks for reading and keep building awesome.
Until next time!
Ian B
P.S. You can also find me on Twitter: @ianaldo21
One thought on “Stop Following Best Practices!”