Live data from Hacker News

The Productivity Mirage

frantic.im

131–140 of 164 posts

Re: The Productivity Mirage

#131
post #44

I 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…

> 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

I think a lot of this comes from beginners skipping some steps because they want to be accepted and taken seriously.

To be, rather than to seem, takes time, and you gotta earn your meals in the interim.

Re: The Productivity Mirage

#132

Earlier quoted context omitted.

I think the downvotes are for saying positive things about AI. HN doesn't like that ;) 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-change…

> 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). Are you building it if the LLM does it? I'd say the negative reaction comes from this.

You are anthropomorphizing LLMs. They are just tools and cant build anything. He is responsible for the code, he built it.

Re: The Productivity Mirage

#133

Earlier quoted context omitted.

I truly believe a lot of people don’t really realize how good it is when you have a good environment for development work. It’s straight thinking to doing. And it’s not even about vim/tmux or emacs. You can do so with sublime or IDEA. In the pragmatic programmer book, it’s called editor fluency.

It’s a balance. It’s easy to spend more time dickering with tools than you save by having those tools. I used to have this amazing neovim setup that worked exactly like I wanted it to. Unfortunately, it was fragile, and while it was theoretically infinitely flexible, practically , it was too big of a PITA to change to be flexible on the run. Then a couple of unrelated plugin changes caused some big problems with my s…

I did that same circuit (except it was emacs to VS Code) for me - same experiences and reasons. I also used CLion for a couple of years for C++ - but in that case I never even bothered trying to use anything else. I could not get the bindings quite how I wanted in either VS Code or CLion, but I made it tolerable eventually.

I'm on neovim now, and the reason is coding agents. It ported my Spacemacs bindings to Astrovim in a few minutes.

Any feature I need to add, I just tell it and its done in a couple of minutes. Anytime I run into something that doesn't work quite how I want, I just tell the agent and boom, done.

I manage all my dotfiles this way now I think it totally changes the calculus. I'm even considering giving Nix another go.

Re: The Productivity Mirage

#134

There's a bubble where VC backed companies are not producing anything that people are really using or paying for. So to justify their valuation they instead try to show just how productive they are. Surely if they are this busy and productive they must be worth something? (This could also explain the hype around AI which is all about "productivity/how" and nothing about "what") This article compares these kinds of co…

Game developers put tons of effort into tooling, just not especially into text editors.

Re: The Productivity Mirage

#135
post #44

I 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…

This!

Live to work? No!

Work to live? No!

Live and work to Emacs!

Re: The Productivity Mirage

#136

This 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.

Three or four years ago I landed on a desktop that let me keep my tiling but never think about placement. It took a few disconnected days to get it just right, but I haven't changed more than the occasional line in the config since.

I hate thinking about configs now. My config lets me glide through using my computer without much thought, which IMO should be the point of configuring one's setup, so you don't have to think about it. People comment how fun it is to watch me navigate when I'm in a flow(mad at the computer). Sadly, with wayland taking over, my setup isn't long for this earth and I'm dreading the level of effort I'm going to have to put in to get a remotely comparable setup.

The biggest drawback of wayland/hyprland/etc is just how much bullshit one has to wade through for a working desktop. I don't want to learn desktop rendering just to have a dynamic wm that can open a file picker. I rather give an attacker my login creds than drop x11 at this point.

Re: The Productivity Mirage

#138
When I was a trainee at university, there was a math professor who worked similarly, with a bare text editor, when writing algorithms for his research. He said he wanted the coding to be slow, so he had time to think the problems through properly. When we automate all the routine away, there's no space for the creative thoughts that we get when our hands are busy.

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.

Re: The Productivity Mirage

#139
I 100% agree with this (and remember Bob from my time at Facebook, too!). Picking the right problem matters, but I also think there's an underlying quest for status that leads to a lot of productivity theatre.

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.

Re: The Productivity Mirage

#140
post #57

I wonder if any old software companies like amazon, microsoft, apple, or google have data on how many prs a software engineer would produce per day over time. I wonder what that major spikes on the graph would be? live reload? vscode? faster and faster laptops? llms? I have a hunch the amount of prs written per day per engineer is likely the same or only 10-15% higher.

I have that data for my small team starting from the pre-AI baseline, adding Github copilot doubled PRs/dev/day and adding Claude Code multiplied it by five (from baseline)
Post reply on HN