Are you lazy? That may not be a bad thing

I’m sure you have heard it before. “A good programmer is lazy.” I often hear it when discussing DRY, taking it to mean that you should not repeat code. The train of thought is: if you are lazy, you don’t like doing things twice, so a lazy programmer will naturally tend to write DRY code.

DRY is not so much about not repeating similar code, though. It is more about not repeating knowledge, though there is still value in not repeating similar code ¹. What does that mean for our “Good programmers are lazy” quote? If we can’t be good by avoiding repetition, what other aspects of being lazy make us better programmers?

Turns out being lazy is a trait of many high performing “creatives”. These people are often seen as lazy by their peers because they refuse to do the stuff seen as important to advance your career, your public profile, or your “sociability index”. (No that index doesn’t exist, AFAIK, but it sounded nice.)

So how come that Nobel-prize winners, highly acclaimed authors and other people that produce stuff seen by others as incredibly important, are considered, by those same others, as lazy.

Cal Newport spent a decade figuring it out.

He has come to the conclusion that it all revolves around the difference between “deep work” and “shallow work”. Between work that is cognitively demanding and work that doesn’t require intense focus.

The “Lazy producer paradox” as Cal Newport calls it, arises because “lazy” producers actually aren’t lazy at all. They optimize for deep work. They’d rather do deep work than avoid being called lazy. They prefer to focus on what matters rather than on “busy work”: work that makes you look busy but doesn’t produce much. He wrote a book about it, “Deep Work: Rules for Focused Success in a Distracted World“, that was published early this year.

Haven’t gotten around to reading it yet. Put it on my to-read list, but may not need to read it.

Developers, and any other “knowledge” workers, should have no problem relating to the distinction Cal Newport makes. We talk about it as the desire to stop talking and “get to the real work”. We’d all much rather spend time designing and writing code, debugging bugs, than spinning our wheels with administration (time writing, keeping the issue tracker up-to-date) and meetings.

Now don’t get me wrong. I’m not advocating that developers should avoid meetings. While meetings do take time away from individual developers’ focus on “what matters” in terms of design and code, meetings are an essential part of “what matters” when you are part of a team. At least, the meetings that are focused on “what matters” to grow a group of individuals into a team and to improve as a team.

So, are you really lazy? Or are you just avoiding “busy work” and being called lazy?

¹ Eric Lippert talks about DRY being about a single place to put knowledge in “DRY out your policies“. While Herman J. Radtke III shows there still is value in drying out “similar code repetitions” in “Misunderstanding DRY“.