Every now and then I mention to other developers the value of laziness in their work. Usually this results in laughter and confused looks all round. How could that possibly be a good thing?
It turns out that a lazy attitude in your approach to work can be a very good thing. Product development and the engineering challenge involved is often complicated. It's very easy to make unnecessary work for yourself and introduce accidental complication.
This premise applied to product development is summarised beautifully in the Lazy Product Manifesto. The nature of effective software development seems to emerge from maximising the amount of work not done.
So how can you focus on maximising your laziness as a developer?
Lazy developers don't exhaustively list tasks in backlogs. They work only on what's necessary and iteratively discover the next thing to work on. They know that doing nothing could actually be a more valuable option and are constantly mindful of how they use their time.
They are happy to eliminate their own tasks and find easier ways and processes for the work they do. They discover when automation is actually worth investing in rather than dogmatically applying it everywhere.
The laziest developers look for excuses to write as little code as possible. They know that code is an expensive thing to create, change, learn, document, store, version, release, operate and retire. There may be a chance of turning it from a liability into an asset if they put it in the hands of users.
Lazy developers avoid the introduction of unnecessary frameworks and libraries that they need to learn and configure. They aim to produce the simplest thing that will possibly work and then consider the benefits of various technologies later.
When they do decide that code is worth writing they are guided by tests derived from customer conversations and are happy to rewrite things and start again.
Lazy developers build their pipeline to production as early as possible. They focus on making the job of delivering software to users a first-class activity. The pipelines they create are automated for maximum laziness and have the agreed standards for safety and quality built in.
They practice test-driven development and constant refactoring, applying software design principles and patterns to make their code as deletable, changeable and testable as possible. They use cloud services where they can to make things quick, safe and easy.
Lazy developers work to identify and address potential problems (dragons) as soon as possible. They focus on the riskiest, least understood and unknown tasks so they can reassume a position of maximum relaxation and laziness.
The longer that potential unknowns are left, the more likely they are to become a bigger problem. Lazy developers know this and constantly seek ways to reduce or decompose problems.
Laziness is best achieved by focussing on effectiveness and customer outcomes rather than productivity and output.
Product development and engineering is not comparable to the production of widgets on an assembly line. Optimising for productivity and output makes little sense. Lazy developers know this and identify potential outcomes with their users that might have a beneficial impact. They develop products and software by collaboratively learning how they can offer maximum business value.
We each have our specialisms and skills that make us uniquely valuable in a team. Our effectiveness is diminished when we get stuck and have to wait to ask someone else for answers. When this happens question queues form.
Learning and effectiveness are enhanced by working together. The lazy developer doesn't need to slowly investigate answers for themselves if they can get help from their colleagues whilst learning from them along the way.
Lazy developers focus on doing less to deliver the same rather than increasing output to deliver something bigger and more complex.
They focus on reducing the effort that it takes to do their work through continuous improvement. They also offer to help others when required with the goal of improving the overall capability of the team.
Laziness is an attitude that can guide your approach and practices. The aim is not to be literally lazy but rather to operate from a position of value rather than work.
It seems that an appreciation for laziness might be one way to understand the nature of software development. Many of the most effective developers I've met have a deep appreciation for the value they are offering.
I'd be interested in any ideas you might have to maximise laziness....