The Productivity Mirage

I have a bunch of small productivity tools I made to match my workflows: tiny shell scripts and functions, custom Emacs functions and settings, small tools to control windows placement, etc. Cumulatively I spent many days building and adjusting it.

But when I need to jump into a task, things just work. Syntax highlighting is there, code navigation is there, code analysis is there, I can rearrange things in my area of attention the way I want with a couple of keystrokes, I can drive git the way I want with a couple of letters. I don't have to tweak anything. Nothing bothers me, nothing distracts me, nothing wastes my time and breaks my concentration by requiring legwork.

(Same applies to my mechanical and electrical tools. Mostly.)

Invest in your work environment. Adjust your chair. Adjust your shell prompt. Adjust your editor settings. Comfortable? Good. Now you can forget about them all, they are just there working for you. Concentrate on the real problem you have. Godspeed!

The skill of concentrating on a problem is much harder though. Endless tweaking of your tools that eats all your time can be a sign that you are just trying to avoid that daunting and uninspiring task. But this is not the tools' problem, not that simple.

The whole "90% of my time as a coder is spent typing, so I should optimise my ability to type fast" is so, well, wrong. 90% of our time should be spent thinking, and most of that reading.

I solve most of my problems when I'm doing things like chopping vegetables or mowing the lawn. Sitting in the presence of shiny technology does not magically confer one with the ability to achieve higher quality decisions more quickly. I find the opposite to be mostly true. I can massively outperform the development team that my clients have simply because I am not a full time employee and can idle out long enough to think about their problems the slow way. The urgency to keep the status circle green in Teams (and related productivity theater) creates a lot of stupid decisions in many shops.

This article compares these kinds of companies ("nihilists") with game developers who are producing things that people pay for and use. The game developers don't pay much attention to productivity tools because they are too busy producing things.

https://components.news/the-gamer-and-the-nihilist/

> the perennially unprofitable venture-backed startup, for which faux productivity is connected to the generally immaterial nature of its high valuations, versus the game studio that lives and dies by the profitability of its products.

> In a sector of the economy where "it's not about how much you earn, but about how much you're worth," the labors of the companies whose workflows are built on the kinds of productivity apps that today comprise nearly 40 percent of Product Hunt's output are not actually directed at the creation of a thing, but at the appearance of the creation of a thing.

Many types of performance optimization work, including "programmer productivity" are really the engineer's getaway from having to contend with the ambiguity of the problem domain, the politics, the vagueness, the risk of failure and other kinds of suffering.

Alas, solving a problem coming from the world requires confronting the world - a couple of examples are the tedium of mentally working through a user workflow, getting somebody else to cooperate by articulating and proposing a joint strategy and more.

I do not believe in pain for pain's sake, but good delivery has an inherent quality of athleticism, and one cannot be an athlete without accepting that training for the track means proficiency at managing pain - and at the track rather than elsewhere.

Iirc, one of the essays had the moral " many software developers would rather work on the infrastructure to solve the problem than actually solve the problem"

Comes to mind.

The hobbyist tinkering with the programming setup has its benefits (enjoyment) but it’s a mistake to think it matters at all to the end user or indeed — as this post argues — to actual quality and quantity of work when compared to the benefits of actually thinking about the product and the code

Writing code has never been the hard part.

Not for Bob, not for you.

People think -- and rightly in some environments -- that being busy will ensure they're valued. There's no better way to keep yourself busy than to insist on a new tool and become responsible for keeping the data in it up to date. Notion used properly can be invaluable but I've advised a couple companies where "tending the Notion garden" became someone's job despite there being no incremental value there.

The solution to the status problem is to focus on outcomes. No one cared that Bob's tool choice might've slowed him down when deciding the winner of the hackathon. And your manager shouldn't care if you use Superhuman and blaze through your mail or print it out and highlight important passages.

If you're working somewhere that gets that right, or close to right, then you can focus on picking productivity tools / approaches that genuinely matter and lead to better outcomes, ideally faster. In the era of agentic AI, there are more of them than ever before, though you have to choose wisely since there are plenty that could win a Tony for productivity theatre.

There are superstar product developers. Pieter Levels of the world. History has taught me that I don’t have that level of insight. But improving my flow gives me sufficient performance boost to be able to be useful to people who pay me for that.

In the AI world you see it with the overly elaborate prompt markdown files where my agent gives performance reviews to 4 teams of agents each with its own quirky personality traits

I have a hunch the amount of prs written per day per engineer is likely the same or only 10-15% higher.

Similarly to how no amount of efficiency gains would make Microsoft produce quality software, because they optimize for other metrics.

I used to check once a quarter. With AI, I devote 1-2 days a week to the meta-task of improving my tooling, but I'm sure that will fade once AI tooling becomes more standardized.

It's not worth being one of those guys who gets too into the tools, because it can keep you from the actual valuable work. Plus, you are then judged not as a regular engineer, but as a person who is supposed to have some secret productivity sauce, and when people see that it doesn't make more of a difference they can start to discount your opinion.

At the end it is more productive to be focused on the right target, than to gain 15% of productivity because you use whatever tools. Note that this is not mutually exclusive, but putting brain power in thinking about the product, rather than about the productivity hacks, is what matters.

The problem is that most companies don't care about thinking. You may have more chances to get promoted because you are sweating and running everywhere, instead of calmly thinking, looking through the window and developing mental models.

Ahead of the course, we prepared by obsessing over our IntelliJ or Eclipse configs and had intense discussions about this.

To our surprise, the teacher urged us to use nothing but the basic JDK tools and Notepad. He wanted us to learn what's going on under the hood and also told us, that the productivity will probably be about the same.

I stopped at this line

> he was responsible for shipping Facebook Groups

and wondered how can this be a compliment in any shape or form. I mean even considering Fb Groups from its day 1, not the bigger Frankenstein it has become today.

But I get it. "Shipping" was the achievement.

> massive productivity nerd

My "productivity" phase started at the start of college and since then it has a been tapering down every month/year and I don't complain at all.

I wish I did something else (I mean not even related to my studies or field..anything else) when I was actually exploring the shiny wide world of productivity porn. No, it didn't enrich me in anyway.

And I've seen so many seniors (at various levels of seniority over the years) who had stopped giving two hoots about tools or productivity tools in its entirety. It's like you have to reach city A from city B and few people just hop on the car available to them or public transport (this one not in USA) whenever they are ready to leave. But a lot of people go down the rabbit hole of best cars, best fuels, best routes (and then they obsess over their favourite coffee chains along the way), and get in fights with other people on car and other forums in the planning. By the time they could agree on their cars, the other folks who had just gone, had finished their works there, and even took an extra day or two to sightsee and shit like that and they might have even forgotten about that because it was weeks and months ago.

This is not too much of far fetching. This is actually quite important in early career states and habit and ideas set in during that time.

What has rather worked for me far more/better is a good place to work, environment, lighting, ambience, noise, temperature, material physical comforts available, maybe a bit of easy variation (as needed; not as forced upon) et cetera. But I think these things work differently for different people (and at different ages).

I like to marie kondo my tools -- if it is not bringing me joy to use or making my life easier, I yeet it. If it is, it stays.

In it he talks about how making things easier to do via scripts is a good thing. He even has a system of using `,` as a prefix for all his own scripts just to make them discoverable with ,<TAB> :)

It applies especially now, in the age of AI agents. When it's so fast to build things, I need to deliberately stop once in a while, and think if it's actually worth it to go down some rabbit hole, or if I should assess what the real problems are.

Back then every IDE needed minutes to load a tiny project and it was still much less efficient to open a file.

"If the iron be blunt, and he do not whet the edge, then must he put to more strength: but wisdom is profitable to direct." (Eccl10:10)

No syntax highlighting at all.

And it is a commercial product, I'm not talking about a pet project or hobby.

It amazes me, really.

The main idea of the article is not clear, and the structure of it is not good to read

One usually doesn't have to fall back from these too often because so many machines have them and its the fallback that I find so tiresome - having to get some other muscle memory going for a tool I haven't used in a while.

Level 2 would be strace - because it's so incredibly useful when trying to find out why something isn't working as you might expect.

I don't claim to be highly productive though - just old. Productivity for me comes from making up my mind what to do and being able to visualise it. Usually there's a massive period of unproductivity before every brief bit of decent work. If I was more decisive then people might know my name :-) but I'm obscure like most of us I presume.

I once spent 9 months trying to figure out how a piece of software should be built - I wanted it to be perfect - while my bosses agonised over the delay. One night, in a bout of anxiety and just trying to get something to show my bosses, I sat down at around 7pm and just started riffing away in the editor. I ended up working through the night. By 5am it was done. By 9am it was in production. By 11am the first customers were giving us money. I didn't need to edit it again for 3 months. That was the moment I decided to ignore an old quote I'd been handed and had until the point believed had real truth in it:

"Give me six hours to chop down a tree, I'll spend the first three sharpening the axe" - attributed widely to Abraham Lincoln, but as the other saying goes "90% of the quotes you read on the Internet are misattributed to the wrong person" - Mark Twain.

There are some situations where the preparation is necessary. If your axe is blunt, it'll never cut down the tree, even in 6 hours. Getting it sharp in the first 3 hours means you might finish the task early, for less physical effort.

But more often than not, you're just procrastinating. You could go find another axe. You could find that the axe you have is just fine and gets your tree down in an hour rather than three hours of sharpening followed by half an hour of chopping. But by spending your time sharpening, and not chopping, you have the illusion of telling yourself you're working towards your goal, but you're not. And guess what, sharpening is a lot easier and a lot less sweaty than chopping, so it's more comfortable too - what's not to like?

YAGNI, Yak Shaving, axe sharpening, Rimmer's Revision Timetable, they all bring into focus different perspectives of the same problem:

Doing a thing that isn't the thing, isn't doing the thing.

Yes, if your editor config is distracting and you want to fix something, go find a quick thing and move on. Installing a tiling window manager and a global keyboard shortcut app of some sort might make things flow a little better, but spending days optimising is likely poor ROI.

Just try and do the thing. Build something. Stop planning to build something. If you aren't sure what to build, spend 5 minutes trying to build something and figure out what's actually in your way (hint: it's not your editor, it's not your lack of gdb knowledge, it's not that you're not using the hottest new programming language or that new agent/skill/model people are talking about), and find the possible quickest way to get back to making progress.

Yes, you need to think about prod. The more senior you are, the easier this comes naturally, but writing tests is doing the thing, not procrastination. Putting in operational and business metrics is doing the thing, not procrastination. Why? Because those are part of the thing. Your prompts are not part of the thing, and neither is your tmux config.

As an aside, LLMs can maybe help here (but don't over-engineer the harness): I have a side project where I feel I need to pick up a lot of theory on reinforcement learning, I could do with a refresher on partial differential equations, and I also want to learn some more advanced socket programming in C (trust me, all these things combine into a single thing).

I could have spent the next three months reading books and doing courses and then started on my project, but what I've done instead is get Fable to build out a curriculum where I build the relevant parts as I'm learning.

The first spec it came back with told me I had about 7-10 months of work ahead of me, but I could see (at least in the early stages which I understand better than the later stages), I'd be in a virtuous cycle of learning → applying → learning → applying → ... and within the first couple of weeks I'd have some basic harnesses that showed progress and have some of the theory down too.

This, I think, is a valuable way to structure the learning without procrastination. A personalised tutor who can help you fill in the gaps in your knowledge as you build, so you build the right thing and learn, but you're not just procrastinating up-front, feels good. And, if I get 3 months in and have enough knowledge to realise the next three months are not quite right, I will have the knowledge to re-prompt, re-draft and move forward.

I think thats exactly the problem

1. We had an engineer who worked remote (us in Silicon Valley, him in Central Europe) in the early 2000s. He was - and still is, I'm being vague to protect his privacy - massively productive. He generated reams of high-quality code at a shocking rate, and was an all around star performer: supporting others on the team, fixing bugs, writing docs, super nice guy. We joked that he must have been farming out work to the rest of his town.

We finally get him to visit after a lot of challenges securing a visa, and we are super excited when he shows up in the office. He brings a tiny laptop with a screen half the size of a 13" Macbook Pro and sits down and starts coding away. I can't remember which editor he used - vi(m) or emacs - but someone asks him after an hour what machine he used at home and if he'd like to borrow a larger screen / desktop? He's like, what are you talking about, this is my only computer.

You could hear the crickets as every member of the team has the same thought: if he's that productive on a teeny laptop...

2. Our company did the first Oracle ERP implementation on Linux, which in the early 2000s was a big deal. It was very painful - we had to fix a lot of bugs alongside the team from Oracle at every level of the stack. After many rounds of escalations we told Oracle we needed a lot more horsepower, and they agreed to send their best consultant, pitched like the Harvey Keitel cleaner in Pulp Fiction. The Oracle team in our office held him in awe: "Oh, X is exceptional!"

The guy shows up. Very friendly, soft-spoken, unassuming. I agree to be his handler for the first week. We sit him down at a Windows machine, and I'm like, what do you need? He's like, I just need access to various systems and this stock Windows installation is fine.

He opens Notepad. He can't touch type, he hunts and pecks. I'm thinking: zero percent chance this guy is The Wolf.

I watch him write SQL and PL/SQL, huge queries, with no reference material and no distractions, entirely in Notepad, slowly picking away at the keyboard. I realize: he does not make typos, he does not backtrack. He looks at the problem, thinks for a few minutes, talks to people, thinks a bit more, runs a few exploratory queries, grinds out some code, pastes it in and runs it, on to the next. Obviously not every query ran perfectly, but he did 90% of the work in his brain and and then just played out the tape.

He did more in a few weeks than the rest of the consultants did in six months. I'm not sure he ever touched the delete key, and I'm certain he used nothing but Notepad.

Long story short, you see a few of these people in action, and you stop assuming anything about what great looks like. Never underestimate the people who don't look like you / use a fancy editor / fit the idealized high-productivity image in your head. Judge them by how they treat other humans and what they output.

How is this *not* real productivity gain?