The Good Lazy Developer

I've said several times that a good developer is a lazy developer, this is not to suggest that they should be lazy in their attention to detail or their willingness to apply their skill to solving problems.

It is more about proper application of that skill and maximising the benefits that it can bring.

Engineering effort is not a commoditised product, it doesn't simply scale with the number of engineers in a team or with the number of hours each engineer works.

Its a finite resource that needs to be deployed with some calculation and forethought to ensure value is delivered.

Solve the Right Problems

Developers are very often compulsive slightly obsessive people who sometimes focus their effort on the minutiae of a problem or a piece of work.

While this attention to detail is partly what makes them good developers it is a beam that needs to be carefully focused to eradicate the most important problems.

A good example of when this is not done is when an inordinate amount of time is spent perfecting the UI for a customer journey that actually under the hood doesn't work.

Another example would be expending large amounts of effort on an edge case that is unlikely to happen or can be managed in a different non-technical way.

Whilst you always want developers to see the whole picture of a piece of software you do want them to adjust their attitude to when they are happy to say something is done, or at least done for now.

Customer journeys delivering the intended outcome should be such a staging post, a good lazy developer just wants to get to the point where things work and save polish and refinement for another day.

It may be that we don't want to ship until this polish is applied but we still need to approach the problems in the right order and ensure effort is concentrated in the right areas.

Automating the Housework

Developers time needs to be maximised on the furtherment of the product or system they are working on, the implementing of the pipeline to produce this shouldn't be a task that requires continuing application of effort.

When properly implemented the DevOps movement is an answer to this dilemma.

A scrum team contains a technical resource that can be equally adept at using technology to implement an autonomous and continuous pipeline of delivery as it can be at implementing the desired business outcomes.

Whenever a task becomes repetitive or onerous the good lazy developer wants to develop a way to avoid having to undertake that task again and instead concentrate on the production of new features or improvements to the code base.

The nature of these tasks is likely to be different in different teams but the fundamentals of building, testing and deploying code are common to all teams and the slicker these things can be made the more time and effort is conserved for solving the right problems.

Avoiding the Maintenance Headache

The majority of developers prefer to be creating code rather than maintaining it but none the less keeping an existing code base going is an unavoidable task.

The good lazy developer wants to reduce the impact of bugs or requested changes for a pre-existing code base. To do this they anticipate this requirement for change or modification coming and deploy the tools of loose coupling and strong cohesion that they have at their disposal.

This makes the code testable and composable, not only does this make the impact of change easier and more predictable, when combined with an automated pipeline it can prevent problems before they are shipped and reduce the impact even further.

Well structured thought through engineered code helps a team develop lazy habits by allowing them to keep to a minimum the amount of effort involved on change activities and avoid the cycle of tearing things down to build them back up again.

The majority of the time when we are referring to good lazy developers we are referring to an active dislike of repetition of the mundane and a preference to expel effort on the new and exciting. 

We are also referring to an understanding that developing software is a long term aspiration more than it is a short term activity. You'll never solve all the problems so make sure your plan of work address the most important ones first rather then being side tracked on the areas that potentially technically fascinating but ultimately of secondary or tertiary importance.