Don’t Love Coding

If you love working on your tasks too much, you’ll want to prolong them artificially. But work efficiency demands that you streamline your tasks, shorten them, and ultimately aim to eliminate unnecessary steps. So, you shouldn’t love your tasks.

In my field, developer experience (DX) often focuses on making coding more enjoyable. However, I worry that if coding becomes too rewarding, developers may prioritize it over less exciting but essential activities like documentation, testing, design, and reflection. They may end up writing more code than necessary, chasing the dopamine hit from a new framework or library, or enjoying faster feedback loops.

Metrics like lines of code or commit frequency, often used to measure productivity, can fuel this obsession with coding (“codaphilia”). The fast feedback from developer tools—file watchers, auto-reloaders, and others—provides “cheap” rewards, making slower, more thoughtful tasks even less appealing.

A Radical Solution

One extreme solution? Make coding not just less pleasant, but actually painful. Not by bringing back punch cards or making front-end developers hand-code assembly, but with a Pavlovian twist: brain implants for all coders. These implants would deliver a micro-jolt to the pain center for every compiler error or missing semicolon.

In such a world, developers might spend less time enjoying the act of coding and more time with a whiteboard, catching high-level logic issues before even touching a keyboard.

A Serious Takeaway

On a more serious note, we should stop loving our tools and start focusing on solving real problems. In any profitable project, there’s a human pain point worth addressing. Our love should be for alleviating that pain, not for indulging in the act of coding itself.

Consider a surgeon who loves suturing. If his enjoyment of stitching surpasses his focus on the patient’s outcome, he might extend his work unnecessarily. The goal isn’t to love cutting and stitching—it’s to improve lives.

Similarly, the goal of a developer isn’t to revel in micro tasks like writing code. It’s to fix larger, abstract user problems. Progress should be measured in how effectively we solve these problems, not in how much code we produce.