The post’s core claim is simple: developers often confuse visible busyness and elaborate tooling with actual leverage. It uses a story about “Bob,” a prolific Facebook engineer who won a hackathon and shipped major features while working in a barebones editor, to argue that the biggest productivity gains usually come from picking the right problem and driving it to completion, not from shaving seconds off keystrokes or building an elaborate personal stack.
Most people bought that, but with an important refinement. Good tools absolutely matter when they disappear into the background. Several experienced engineers described years of accumulated shell scripts, editor bindings, window management, and stable defaults that now let them start work without friction. The line they drew was sharp: build or choose tooling that becomes invisible, not tooling that becomes a second job. That is why some had moved away from fragile
Neovim or
Emacs setups toward
JetBrains,
VS Code,
Helix,
Ghostty,
fish, or other batteries-included tools, while others said coding agents have flipped the equation back by making custom environments cheaper to maintain.
A second strong theme was that typing is not the bottleneck nearly as often as people pretend. Many said their best work happens away from the keyboard, on walks, doing chores, or after reducing monitor count and ambient noise. Others pushed back on the idea that coding should be pure up-front thought, saying they reason by sketching, debugging, and iterating in code. The practical consensus landed in the middle: speed matters most when it shortens the loop back to understanding. Fast navigation, low-friction edits, quick scripts, and better startup times help because they preserve context, not because raw text entry is the job.
The broader criticism went beyond editors. Commenters connected the piece to “productive procrastination,” gear acquisition syndrome, and startup productivity theater. Shiny tools,
Notion systems, AI harnesses, and agent orchestration all create the feeling of progress because they are tangible, socially legible, and easy to admire. They also let people avoid the harder work of product judgment, domain understanding, and confronting ambiguity. Several people extended that to company culture, arguing that some organizations reward visible activity, green status dots, and garden-tending over calm thinking and measurable outcomes.
AI showed up mostly as a modern version of the same trap. A few people said
Copilot or
Claude Code clearly increased throughput and helped them cross the activation barrier to start building. But even supporters said the same old failure mode has simply moved upstream. Instead of over-tuning
Vim, people now over-tune prompts, skills, routers, and agent teams. The useful framing was not “AI or no AI.” It was whether the tool compresses the path to a better solution, or just makes busyness feel more sophisticated.