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.
Especially in the age of LLMs I think a lot of us hate the current tools that force you to context switch between N agents and terminals. Constant context switching takes the joy out of work and prevents you from getting into a flow state. I hope someone figures out the solution.
Nowadays I often feel that that is a better spend of my time. Especially because it allows my mind to wonder about the next thing and what I could have missed. Before I was doing the context switching dance I felt I was going at 10x, but realized I was only perhaps going at 2x. Now I have severely reduced the number of threads, mostly to a single thread, and ask smaller questions. My sense is that I am probably now going at 2.5x but with my sanity restored and with a much firmer grasp of what is going on.
I also find myself coding more skeletons and letting an agent finish it, because I am again taking the time to think of the shape of the solution. The end result is better then when I allow the LLM to flail about in the codebase.
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.
Any software engineer who proclaims "90% of my time is spent typing" does not understand two fundamental industry axioms:
Software is the manifestation of a solution to a problem.
Define the problem which needs to be solved.
When making software, remember that it is a snapshot of
your understanding of the problem. It states to all,
including your future-self, your approach, clarity, and
appropriateness of the solution for the problem at hand.
Choose your statements wisely.
All of this is to say; I agree with your position.
Not sure about you, but I do a lot of thinking by typing code...In fact, I think it would be very hard to think without actually typing code..
I don't think this is exclusive to coding. Even general ideas are refined if one tries to put them in writing.
I used to smoke a lot, and every time I went to smoke outside I'd think about what I was coding and find some stupid mistake just from thinking about it away from the keyboard.
Now I go for a walk and 9 times out of 10 it's the same, I write better code because I thought about it away from the keyboard.
This also works with vibe coding, I find - I think of better approaches to the codebase when I'm not in front of it
> 90% of our time should be spent thinking
Thinking and typing often happen at the same time. Its much easier for many people to reason about a problem by writing and changing the code, and it's also why LLMs can significantly reduce code understanding even if you read everything they wrote.
This was me, until I got AI. Now im building cool stuff that I never would have built (but also slowly destroying what little skill I had and not knowing much about the underlying code). Of the code I do know about well, I am fixing and improving my old code and being amazed (but probably not deeply learning) with new tricks and techniques. The focus on setup to me was always my mind playing a trick on me. The AI reduced the "hump" I need to cross so I just try it. Its really another form of perfecting your setup.
Focusing on the setup for some might be a way to avoid the hard thinking part that comes with immense practice and focus. Its a hump everyone has to cross. It comes easier to some but not others. I remember doing exactly this when I was unemployed traveling Europe wanting to get into a software engineering role after being boxed into a QA testing role for years. I was a CS grad and did this same stuff in college to my detriment(thats how I ended up in QA I guess). I paid for InterviewCake and spent countless days in European hostels and cafes doing nonsense like perfecting my setup or editor instead of focusing deeply on the problem set. This might also be a symptom of ADHD. Recently started medication and the immense change in productivity has recently made me weep that I wasted half my life doing things like perfecting my setup instead of actually doing something.
And yes, messing about with skills is the new messing around with setup. It's a rabbit hole.
I'm a massive, massive, believer in The Cult of Done [0] especially "the point of being done is not to finish but to get other things done". Allowing myself to finish something badly so that I can move on to the next thing was a game-changer for me. And, of course, I found out that it doesn't have to be what I would call perfect for others to appreciate it. Getting something shipped is way, way more important than getting something perfect, and often my procrastination around the fear that it wasn't perfect was stopping either.
[0] https://medium.com/@bre/the-cult-of-done-manifesto-724ca1c2f...
Are you building it if the LLM does it? I'd say the negative reaction comes from this.
If you really must bring up AI here, a more relevant comment would be how you may over-complicate your AI workflow, over-focus on promots, or something along those lines.
I don’t know if that’s accurate for most of us, who are simply humble CRUD app developers.
This is somewhat misguided thinking in that, while very true that people who care more about their setup than getting actual work done do exist, "Optimizing for typing" really means: "optimizing for how quickly you can get back to thinking."
I've seen some experienced programmers use simple editors extremely quickly and others use IDEs very slowly. This short article does not dive into things like: "Does Bob need to right-click his mouse in the right place and choose 'split vertical' or does he just make that shit happen in an instant?" I've done a lot of pair-programming in my career and many people, even if they are good developers, feel like I'm watching my boomer parents use a computer.
Of course, in the end your output is all that matters (which I realize is the argument of this article), but there is definitely something to being able to use your tools of your choosing efficiently (which it sounds like Bob does).
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.
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.
Also used neovim for 2 years or so and hated every minute of it having to configure LSPs and wwhatnot. I now use a mixture of VS Code and IntelliJ and its good enough for me.
I kept using vim motions however.
I have a hunch the amount of prs written per day per engineer is likely the same or only 10-15% higher.
Writing code has never been the hard part.
Not for Bob, not for you.
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).
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.
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.
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
to be fair, the car mod people's end goal is just modding their cars mostly. there's no end goal like there is with software (a product).
I think people just get preoccupied with things that make them feel good and are simple and have immediate feedback. Not to be pedantic, but I would argue the more accurate analogy to this is the photography community. I had a period where I was really obsessed with photography and realized the majority of people love just...buying shit. All they did was just collect cameras and lenses and took extremely mediocre pictures. Turns out actual creativity is a lot harder and less immediately satisfying than the dopamine hit of buying some new lens, or changing your vim colorscheme and updating some alias for the 100th time. I'm sure there's some psychology behind people being too afraid to actually produce something because then they actually put themselves out there whether that's through some website or a photograph.
https://en.wikipedia.org/wiki/Shopping_addiction#Gear_Acquis....)
https://stanforddaily.com/2025/05/27/productive-procrastinat...
Buying ever more elaborate keyboards and endlessly tweaking syntax highlighting and Kanban boards will always loose to just getting on with it.
But this article mirrors my thinking on every new notes app, or new “second brain,” or somehow new or better version of Jira, etc. There are real productivity gains and losses and a lot of theatrics.
Nah, man. I would be a LOT more productive if I didn't have to wait all day for Jira tickets to load every single time, or that dropdown to load, or that popover to show, …
To be fair I mess with “how” I use or orchestrate the harness myself, I still can’t say anything I do that benefits me is more than placebo. At least from my projects. I think it matters easily for the things that can be patched like Context7 helping with API knowledge, and less for those that can’t like whatever “prompting style” attempts to address.
Maybe for those, you can say it matters in making agent use more subjectively ergonomic? So less of a correctness thing and more of reducing fatigue.
The easier part is maintaining and tweaking that code, but do not underestimate the value of the former.
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
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"
"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)
How is this *not* real productivity gain?