Fooled by "productivity"

We usually think productivity is just about doing the same stuff faster. But productivity means doing things that actually matter more. That takes a totally different mindset, one most of us (including me) haven’t really learned. I get fooled by this every day. Let’s take a look at one “productive” day of mine and see if you get fooled too.

My first challenge is getting from bed to work as fast as possible. Do not want to waste precious minutes taking a mindful no-stress slow relaxed morning. Bike, train or car, does not matter, as long as I can squeeze in a podcast like The Engineering Room or Rework, so I’m armed with killer arguments by the time I hit the coffee machine.

Great, locked in at 8:10, coffee and oats by my side. In front of me: a curved screen, a cooling stand with my 128 GB laptop on top, vertical and horizontal mice to avoid arm pain (from not taking breaks) and a keyboard ready to receive my blazingly fast Vim motions. My calendar proudly shows two hours of "busy” (hell yeah I am). I’m already assigned to at least four Jira tickets, because if there’s a gap in one, we definitely don’t want to risk filling it with stupid things like thinking.

First ticket: the user says they want a button used for uploading company documents. Weird, I thought we had a universal upload… STOP. Too much thinking, not enough typing.

Start the program in debug mode, navigate to the page the new button should be, locate some text on screen, search that text in the codebase, edit the found file and refresh to confirm you’re in the right place (which I am on a productive day). Typing… typing… coffee sip… tap tap tap… typing… the keyboard is practically smoking… almost done… buzz buzz calendar says: daily stand-up time. Perfect. They just need to know that I know exactly what to do, need no help and that I will probably finish today.

Fresh out of stand-up, my colleague summons me via git blame and I am inevitably seated at their keyboard. I see my colleague type git pull and I see my opening for an efficiency lecture.

My colleague asks about the code I am on in git blame. I’m only there because of a refactor, I have no idea what’s actually happening.

Back to my own ticket. Almost done. Testing manually, works perfectly. But just in case, I ask the LLM for improvements. My solution is a couple of lines, but the LLM spits out async streams, chunked uploads, retries with exponential backoff, and checksum validation spanning several lines of code. Writing that in a single day is obviously peak productivity.

The day is almost over, and I want to move the ticket to Done. Some automated tests are still missing, but the code is solid, the developer who’ll get the PR won’t mind, and the product manager would rather see the ticket move quickly to impress higher-ups.

PR sent. PR accepted. Ticket moved. What a day. I survived another day of looking busy.

Now, in another parallel universe, my day might look very different. It would start by understanding what the user is actually trying to achieve. I might notice that the universal upload button already works, write a test for that specific use case, or even ask the user a few clarifying questions. Maybe I’d sleep on it and realize the right answer is to say no, the system simply is not designed for that.

Let us not be fooled by the 10x productive engineer. Sometimes the most productive line of code is the one you never write. Often, the bravest engineer is the one who says no. And maybe, real productivity is listening to that weird colleague who says: “let us sit in silence, stare out the window, or maybe take a walk, and think about it first.”