I’ve spent four days at the beginning of March this year working on immersive hero images in our app. I touched around 250 lines of code all in all, mostly adding new code but also modifying or deleting a few dozen existing lines. And that’s pretty much all I did in those four days. Sure, there were a couple of small meetings here and there and an occasional code review, but overall I’d say that I’ve spent at least 8 hours every day working on this feature. Overall my total output was less than eight lines of code per hour. That sounds not very productive of me, I know.

Recently I find myself not really writing a lot of code. Instead of diving straight into the editor, I think. And I think. And I think some more. I literally sit there staring at my desk. I get up and walk around the room. I take a break and browse the web (but don’t tell my managers about that). And then I push it out to the next morning.

On any given day I find myself spending, perhaps, 10% of the time writing code, 40% of the time debugging it and 50% of the time thinking about it. It certainly seems like a big waste of my time. I should be down there in the editor, banging out line after line, method after method, class after class, throwing it at the device and seeing what’s happening. You know, walking the walk.

But I’ve walked that walk before. It felt good to always be moving and it felt great to always be moving fast. These days I prefer to move slow.

I like to think about this as deliberate brevity. A long long time ago, a French mathematician and philosopher Blaise Pascal said “Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte.” Translated loosely, “I have made this longer than usual because I have not had time to make it shorter.”

I enjoy taking time to make my changes brief and vigorous. In the words of William Strunk, “When a sentence is made stronger, it usually becomes shorter. Thus, brevity is a by-product of vigor.” I believe that every line of code needs to fight for its right to exist in our code base. I believe that every comment needs to fight for that right as well. I immensely enjoy code reviews where one of my teammates points out how I can cut out even more code and make things even simpler, but without losing the overall clarity of what the code is doing.

I am indifferent to productivity tools in general and to debates on which IDE makes programmers more “productive”. When you spend five times as much time thinking about the code than writing the code, the number of shortcuts, templates and auto-completion becomes quite irrelevant. I don’t measure my output by words of code per second or lines of code per minute. I measure my output by the robustness of the path I’m paving, over weeks, months and years.

When you spend half your day thinking about the code, every distraction hurts. Open office plans that proclaim to foster spontaneous exchange of ideas are creating a never-ceasing cacophony of distractions that is actively disrupting the most precious resource we have to offer our employers – our brains. Until they come with a thinking-time switch that envelopes you in a literal cone of silence, they must not progress beyond the corporate facilities planning spreadsheets. I realize that it’s a bit late for that.

Don’t aim to impress me with how fast you can churn out new code. Don’t tell me that it will all be done by the end of business day. It rarely happens, and when it does, I know I’ll find myself wading through vast reams of that code in a year’s time (when you might have already gone to some other project), trying to understand why it is, in fact, so vast. Don’t ask for permission to spend time thinking. And don’t think that spending all that time thinking only to write fewer lines of code makes you a less productive programmer. Be concise. Be brief. Be vigorous.