Trust me, of all the professions out there, the only one where laziness* is an asset is software development.
Consider the following two approaches toward solving a complex problem involving interactions with multiple systems and data sources.
The first lazy programmer hits the ground running. He wants the code done now so he can retreat to his underground lair for another WOW binge. He writes boilerplate for each separate interacting system, and copies and pastes code between different parts of the application as necessary.
It requires almost no thought, and can be executed very quickly.
The second lazy programmer takes a moment to think. She ponders the interactions between the different systems, and tries to model the solution to an intuitive understanding of the real world problem being solved. She uses an object oriented paradigm both in the recreation in code of the problem, but also share common code in a parent-child relationship (no copying and pasting).
It requires much more brainpower up front, and is not as productive from a sheer LOC/day (lines of code) metric.
And the second lazy programmer is the hands-down superior coder. She is a special type of lazy, one who takes a long-term view and knows what true effort expended over time is.
The first programmer is trying to satisfy his short-term laziness and seek an immediate payoff, but in doing so, he ignores the effort that will need to go into maintaining and updating the software. It is inevitable that the software will need to be revisited later, sometimes years, so this is really where the well-honed, long-term laziness is key.
Organizing the code into classes can accomplish three benefits that reduce DPMO. First, since code isn't so often copied and pasted in OO development, we don't see as many transcription-type errors occurring than if the code were copy-pasted.
In returning to maintain a piece of software, it is usually much easier to mentally navigate an object hierarchy than a less well organized pile of code. This is the second benefit. If one isn't as familiar with the code, they can learn it easier by examining the object hierarchy, and how it maps to the problem being solved.
The third benefit is that the code being shared is being shared through the object hierarchy, so everytime object->function() gets called in the code, it is the same source function (for the most part, this is a gross oversimplification).
This means that if a particular function needs to be changed, then it is changed in one place, and all references to it are automatically updated.
This is in contrast to having to hunt through a bunch of copy-pasta boilerplate, and update each instance in the source code.
So true laziness looks for opportunities to prevent more work in the future, at the cost of working slightly harder now, as opposed to doing the opposite by taking short cuts.
I've written, and been forced to maintain, code from both approaches to laziness. The assiduously lazy coder beats the obsequiously lazy coder every time.
*For certain values of laziness.