Be Effective, Not Productive

We are in a creative business instead of a factory floor. You don't want to be productive — you want to be effective.

Niko Heikkilä / 22.08.2022 / ☕️ 2 minutes read

I've recently participated in discussions related to developer productivity. I think productivity is harmful because it can fool us into thinking high-frequency outputs are more desirable than high-quality outcomes.

Productive developers may write 500 or more lines to a feature branch in hours, open pull requests for reviewing the changes, hop on the next task, and return to the previous task to eventually rewrite the code.

For them, productivity is about throwing code over the wall as fast as possible. You only live once, and QA or your client will catch the bugs. They bask in the illusion of productivity and enjoy the dopamine rush, but in the end, they only do busy work, which is ineffective.

On the other hand, effective developers spend their time together thinking, discussing and designing a feasible solution. Then, they write the minimum amount of code to satisfy the requirements. They work as a single team on one task at a time, review it, test it, and deliver it to users. But, to the significant discomfort of a person passing by, they are not productive because they only spend their time talking while one of them is occasionally working.

Similarly, meetings are rarely productive because you typically don't produce the solution during the meeting, but under some circumstances, they might be effective because of the discussions.

The signal-to-noise ratio is a practical — albeit more philosophical than physical — measurement of our effectiveness.

Suppose I work on a software feature alone and produce a solution with a code diff of 50 changed files. When I ask a peer to review it, we debate different approaches, and eventually, we trim down the solution to only 5 changed files. I can proudly say I was very productive in writing and refactoring code. We achieved the desired outcome (signal), but excess work (noise) could have been avoided.

When I work in pairs, my pair doesn't allow me first to produce an insufficient solution. We immediately start the discussion and promptly end up with an architecturally saner solution in the above scenario. However, I wasn't nearly that productive. I might have been watching my pair do all the "work" while I sip coffee. Yet, we achieved the same desired outcome but with a lot less excess work.

Instead of being productive, we should be effective. We are in a creative business instead of a factory floor. You don't want to be productive — you want to be effective.

Back to postsEdit PageView History