There was a study that people using the keyboard instead of the mouse felt they were working faster but in fact they were working slower. A perception thing. Users were more engaged when using a keyboard.
Triggered by both of these comments.. interaction mode dictates a style of thinking. I have to use a mouse, I'm forced to use my eyes, which also means I probably have to use a massive screen. I have to pay attention to some hyperactive Intellisense-like feature, I'm forced to remove my attention from the problem.
It's like saying you're convinced people reporting they feel more productive in a mauve-coloured room are liars, or those that drive automatic vs manual. Maybe they just find muave a restful colour?
I think most people who strongly identify with tools like vim do so out of a sense of identity-building to "be the kind of developer who is good at vim" / embody some kind of aesthetic or in-group signal moreso than an actual desire to be more effective at getting work done.
As long as you don't have some kind of stochastic or >5s impediment taking you out of a state of flow, most developers' productivity is going be vastly more influenced by their knowledge, understanding, and ability to focus on the problem they are working on than the marginal difference in time it requires to perform some navigation or editing task. Which is not to say that vim is bad or that you shouldn't use it, but that it's just a text editor and if you get triggered by someone not liking it or thinking it's more trouble than it's worth, it might be worth taking a step back and thinking about why it's something that triggers an emotional/defensive response, rather than the kind of reaction you'd have to someone liking strawberry more than vanilla.
> I think most people who strongly identify with tools like vim do so out of a sense of identity-building to "be the kind of developer who is good at vim" / embody some kind of aesthetic or in-group signal moreso than an actual desire to be more effective at getting work done.
This is the exact same sweeping inferential leap as the original comment. I happen to think people who drive red cars do so only because they want to incite a sense of danger and potency in their road opponents, people who wear boots obviously want to identify with Ukranians on the front lines and any claims it helps with their flat feet are obvious rubbish.
Tooling and language obsession is boring and borderline offensive to anyone who has been around for a few years. Imagine walking into someone's workplace and demanding they replace their well worn chair, would you do it? Imagine insisting someone use vim because their IDE didn't have a natural pipe-through-shell-command function.
>> I'm forced to use my eyes, which also means I probably have to use a massive screen. I have to pay attention to some hyperactive Intellisense-like feature
I can quite easily (and often do) use a basic editor while staring at the wall. I've yet to use an IDE where there wasn't some idiotic race between keystrokes and whatever random latency language server just told it to insert parens or a newline after you already typed them, assuming the text is even visible on a 13" screen buried in sidebars and "essential" extensions. They're full attention tools which is a completely different mode of work than is otherwise possible.
It's not to say an IDE isn't a useful thing, they just have their place like anything else. I personally find autocompletion useful for a couple of weeks going into a new language or project after which it's very often more a distraction than a productivity enhancer. Same goes with e.g. Git integration. I wouldn't presume to say a Git integration user simply needs to learn Git in much the same way I wouldn't expect someone to tell me that I can't use Git just because I don't use the IDE Git integration. They're just tools
Do you have evidence to show they are not, in fact, more productive? It's easy to find things where a mouse is comically slow compared to vim. But any kind of religious adherence to tools isn't going to be the most efficient way. Like with just about anything you need to find a balance. An extremely large set of tools is just as bad as an extremely small set.
There are multiple developer subcultures (nominally for productivity but mostly hobbyists) pretty much exclusively motivated by installing and configuring complex, visually-dense, high-learning-curve tooling and editor setups driven by the same psychology.
Besides the cultural association between keyboard navigation and complex tools with being a 1337 h4xx0r, I think there is something to be said about the process of tinkering with and learning how one's own tools work, or more generally experimenting with new, "interesting" ways of working than the default choice (which around where AI was at the time of this study), and being more engaged and thus more knowledgable about one's own work or problem domain, even if the overhead ends up being a poor investment time-wise upfront. Personally, if it took me 20% longer to accomplish something but I understood it 95%, vs 75% if I had done it the "fast way", I would almost always take the 20% latency hit, with the expectation that more knowledge/exposure to different tools and techniques would have much better ROI over time than marginally faster delivery.
There's a certain kind of developer (much moreso the kind all-in on AI in early 2025) who thinks that AI is really smart and knowledgeable and assigns a high degree of confidence/deference to its responses, the same way you might to a venerated subject matter expert or wikipedia/stackoverflow/google search result. To this person involving the AI lends more credibility/confidence in their work and their own understanding of it (vs if they just uncritically copied code off stackoverflow). Better understanding this kind of user made me realize that the quality signals and mental models people build around productivity can vary immensely even within the same profession or team. Productivity-hacking is a lot more about vibes and identity-construction/tribal affiliations than most people would like to admit.
I'm sure this is the case; in both cases, the amount of "things happening" is higher (keystrokes, perceived actions per second, tokens used, words generated by LLM while it's "thinking", back and forth betwee LLM and user, etc) - but does it translate to measurable end results? tickets closed, features delivered, money earned vs cost (personnel + AI + hosting + other costs), etc.
As always this is hard to measure, or will take a while longer yet to draw conclusions from.