Work Smarter, Not Harder
The simplest definition of my mantra of "work smarter, not harder" is:
Using your intellect, skills, established patterns, tools and a fundamental understanding of the problem space to create an elegant solution, instead of a purely brute force approach.
So many people jump straight into trying to solve a problem without actually trying to understand it first.
Sometimes this is due to having a lack of skills or having little or no knowledge of established patterns or training in useful tools, but more often that not it is because they haven't taken the time to understand the problem first and thus they aren't empowered with the information to discover if someone else has come across this problem and solved it before.
The best way to describe "the way of working smarter, not harder" is to break it down into three steps: Do, Recognise, Codify.
Do
One of the most important aspects of "work smarter, not harder" is experience – there is no shortcut to obtaining this. In a previous life, when I was responsible for mentoring, appraisals & promotion – one of the key requirements for a promotion from developer to senior developer was the experience of having seen multiple projects through their lifecycle – from client engagement, through development, go live and operational support. One of the interesting techniques used by advocates of the Software Craftsmanship Movement is utilising Katas to help develop and hone problem solving / development or architectural skills. It's a wonderful notion which aligns with the old saying "practice makes perfect", but while practice helps improve your skills only doing helps you improve your experience and once you have sufficient experience, only then are you equipped for step two…
Recognise
Once you understand and have experience of the complete ALM process you should be equipped to start recognising the patterns, both micro and macro that make up the software development lifecycle of any project. Discovering these patterns offers you opportunities to remove friction, eliminate waste by removing duplication of effort or elimination of the all too prevalent "Not Invented Here" syndrome, which is the cause of so much waste in software projects. By having more experience and having the confidence to question all behaviours in the system you should be able to start recognising patterns such as Process B and Process C have many common features – that could be refactored out into a generic Process A which both C & D could consume. Also being able to recognise that Process A, B and C are really quite fundamental to most projects, yet seem to be reinvented every time, which leads on to step three…
Codify
Once you have recognised both the micro and macro patterns – you should be able to codify them either as patterns, guidance or artefacts (such as code or tools) that can be re-used on multiple concurrent projects. The most powerful feature of an Agile process is the continuous improvement cycle, but one of the most striking One of the most important aspects of Codifying this information is that in this format the knowledge can easily be communicated and shared, unlike the selfish gene, working smarter, not harder is more akin to altruism – it works much more effectively within a community than an individual. When teams work smarter, not harder, compared to an individual, the value of the results can be quite staggering.
