Being busy is easy to measure; meaningful progress is not, which is why productivity often becomes performance rather than real output.
The Productivity Mirage
71–80 of 164 posts
Re: The Productivity Mirage
#72Earlier quoted context omitted.
> 90% of our time should be spent thinking, and most of that reading I don’t know if that’s accurate for most of us, who are simply humble CRUD app developers.
What are those supposedly easy CRUD apps that you are working on? The most CRUDy platform I worked on (it was really a collection of forms and lists) was packed full with integrations to external services. To create a new page, you just had to copy and paste. But to bring in the actual feature requires to write multiple files of business logic and more integration modules to third parties.
My experience with CRUD backends is that you get bogged down in really convoluted business logic and abstraction layers, and most of your time is neither spent writing or thinking, but debugging. (Of course debugging involves thinking, but it requires you to step around, print, inspect, and explore how data flows, rather than exclusively thinking up new solutions). And in my opinion, debugging is easier if you can faster navigate your code and more quickly type or edit small changes.
Re: The Productivity Mirage
#73This is not 'productivity mirage' this is just 'tooling mirage'.
Yea I'd agree. I hate configuring things or setting up custom scripts that could make things easier for me and yet I still work productive on my day 2 day tasks. 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.
same, although I also bothered to learn the standard keybindings of the most popular IDEs of my kind of work (intellij, eclipse, netbeans, vs code). As a plus, I can get started right away on just any dev machine I come across, no expensive customisation needed.
Don't be in love with your code or your workstation. Only the endresult matters.
Re: The Productivity Mirage
#74[dead]
Re: The Productivity Mirage
#75What incredible problem did FB/Meta solve with the Marketplace, anyone care to elaborate? What did they (this guy do) that was not there before or else hard to conceive?
Re: The Productivity Mirage
#76Earlier quoted context omitted.
> 90% of our time should be spent thinking, and most of that reading. 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 literally can't do this. 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…
Yea, that works for me as well. But I can't do that from blank state. I need to be walking away from a long coding session for that to work.
Re: The Productivity Mirage
#77I think it's a false dichotomy. A good craftsman cares deeply about their tools. But the tools are a means to an end, not a toy. 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, thing…
Exactly. It matters that you enjoy working with your tools. Even if they don't make you 10x more productive, focusing on what you're working on and enjoying the process is the most important part. 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 in…
> 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.
Don't do that if it bothers you? My best experience for "agent produces good code following good design" essentially been to always work with one agent, at most two, but in the same project. And while the agent works, I continue taking my notes of what I'm doing, what's next, what the design/architecture needs to evolve to do and so on.
Of course if you switch between five projects, you'll suffer the context switching cost. The best to avoid that? Don't context switch, find other related things to do close to the task you're "outsourcing", or start planning how to validate, or...
Re: The Productivity Mirage
#78spent more time configuring my note-taking system than writing anything worth noting
Re: The Productivity Mirage
#79I think it's a false dichotomy. A good craftsman cares deeply about their tools. But the tools are a means to an end, not a toy. 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, thing…
I think you forgot to explain the false dichotomy part.
Re: The Productivity Mirage
#80This is so important. I've seen so many fellow technologists (and I've skated this myself) obsess about their setup to the point that they're spending more time on that than the actual thing they're building. 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.
> 90% of our time should be spent thinking, and most of that reading I don’t know if that’s accurate for most of us, who are simply humble CRUD app developers.
It's 2026. There are no such developers. LLMs haven't solved programming (yet), but they have solved the common CRUD apps perfectly.