7 ms·

When engineers report that switching to Vim has massively improved their productivity, I can't help but think that the way they work must be very, very differen

by p-e-w 4y ago

When engineers report that switching to Vim has massively improved their productivity, I can't help but think that the way they work must be very, very different from my own. When I "program", 95% of what I do is read documentation and other technical resources, conceptualize what I want to happen, and construct the corresponding logic flow, while trying to anticipate potential problems and corner cases. In other words, most of what I do doesn't involve touching the keyboard at all. If Vim magically tripled the speed at which I'm able to edit text, I doubt it would have a noticeable impact on my overall productivity. In fact, even if you gave me a brain-computer interface that allowed me to manipulate text at the speed of thought, it wouldn't matter much. I touch-type at around 70 WPM, which is very average, but if I two-finger typed at 15 WPM instead I would still be able to produce exactly as much code as I do today. Simply put, text manipulation is not at all a productivity bottleneck for me. I need much more time for thinking about code than I need for writing it. Is this really unusual? How do people operate for whom Vim gives a productivity boost? Does code just flow from their brains into their fingers? I don't get it.

Panzer04 4y ago
I think it's rarely a productivity bottleneck, but that doesn't mean that Vim keybindings and navigation aren't superior in the vast majority of cases to what most people are doing - which is scrolling, mousing about, etc. Vim keybindings significantly accelerate the editing and browsing of existing code in-editor. It also has the convenience of being a fairly common set of keybindings in editors nowadays, as many have an extension that gives Vim keybindings without having to go all-in on a CLI-style Vim editor.
- p-e-w 4y ago
  Every modern code editor has character-, word-, subword-, line-, and page-based navigation, as well as "jump to symbol" functionality. Bookmarks, paragraph navigation, and similar are also very common. I fail to see how Vim is supposed to be superior to that. It has essentially the same navigation features, with different keybindings. And the idea that those different keybindings are somehow "better" is a big [citation needed].
  - Panzer04 4y ago
    How common are the keybindings used in existing editors? I must admit I haven't ever really noticed the hotkeys/keybindings in editors - until I started using Vim bindings instead. There's likely a large crossover between people who use a lot of hotkeys and people who look into learning something like Vim. If they change often across editors, it wouldn't surprise me that they aren't often used, so don't get much evangelism compared to Vim (which has been more or less the same for decades) I only use a small subset of Vim's shortcuts - but most text editors I've used I'd imagine don't have the breadth Vim does (or they do a really poor job of documenting it). Can you point out a doc page for some IDE with similar navigation capabilities to Vim?
    - p-e-w 4y ago
      > How common are the keybindings used in existing editors? The whole point of widget toolkits is that the keybindings for input fields are the same everywhere. I use Linux and almost exclusively run GTK-based apps, and every text input across the whole system behaves the exact same way, with consistent keybindings for navigation, undo/redo, copy+paste etc. This is how good UI should work. Platform conventions are important, and it's the job of individual programs to adapt to them – not the other way round. Vim fails big time in this regard. Can you make Firefox's form inputs use Vim keybindings? If not, there's your inconsistency already.
      - deleted 4y ago
        [deleted]
      - xeyownt 4y ago
        > Platform conventions are important, and it's the job of individual programs to adapt to them – not the other way round. Vim fails big time in this regard. Can you make Firefox's form inputs use Vim keybindings? If not, there's your inconsistency already. I disagree with that. And the world doesn't have to be perfect. If you use Vim and you like it (it takes LOT of effort), you will adapt the platform to the Vim ways whenever possible. Everytime I encounter something I cannot vim-ize, I'm pissed but I have to put up with it. It's like working with Windows. For the browser, you can use Vim binding for navigation, and edit with Vim. But again, this is not mandatory per se to benefit from Vim as a developer.
Aperocky 4y ago
Do you write config files? Do you copy similar unit test structures? or perhaps have you ever found a mouse/touchpad annoying? If purely going off programming speed, probably won't improve much. Most of the time is spent thinking. But it helps reduce annoyance in many other situations - I'm not annoyed when I think, but I'm annoyed when I have to move the cursor, drag it and do it 10 different times when in vim the same is burned into muscle memory and can be done without any thought process, over some config file that I must edit now but not that often enough that it's worth creating a script or template, and then the same apply to templates as well and all levels of abstraction. An extremely common scenario is to copy the content from one enclosed parentheses and into another, and similar class of problems. With vim it's just a few keystrokes, but without it's lots of cursor and drag. These common scenarios are why people use vim bindings. Oh and I can do all of that in the terminal of a remote machine, which happen to have enough memory to run a massive integration test, and build all things a lot faster.
xeyownt 4y ago
If I would type at 15 WPM, I would be MUCH less productive than I am today for sure. The point of using Vim, is that you boost your keyboard interface to the maximum. Obviously, using Vim, means you touch-type. Also, you don't use the mouse. Basically, using Vim, is like having the brain hard-wired to the computer for every task, not only text edition. Everything you do goes through the keyboard, and you don't have to think about it. You scroll through text, search for it, edit it, open new files, etc. For instance, most of the time I don't use any GUI for Git either. I do everything in the terminal, and only use the GUI for partial commit (ie. select which line to commit). I have dedicated aliases for getting history, etc. Also, when learning Vim, you notice that many (Linux) tools have Vim shortcuts enabled. I discovered many of them by chance, out of the habits of using Vim shortcuts.
- p-e-w 4y ago
  > Everything you do goes through the keyboard Except web browsing, which is a huge part of software engineering, and which is nearly impossible to do without the mouse because most websites cannot be reasonably navigated with shortcuts alone. So the whole model falls apart, really.
  - schoen 4y ago
    Some avid vim users will also use https://vimium.github.io/ https://vimium.github.io/ in their browsers, so they can also browse using the keyboard and vim-like cursor movement commands.
  - d4rti 4y ago
    Tridactyl does the job for most websites pretty well as for text heavy sites like documentation it’s very good. https://github.com/tridactyl/tridactyl https://github.com/tridactyl/tridactyl
  - ludicast 4y ago
    I don't find myself needing the browser too much when I code. Other than to reload a page if I'm tweaking something on the FE. Not that I know everything, but I view informational browsing as a distraction while programming. The LSP augments most of the knowledge gaps for me. If vim isn't for you that's cool. But I find other editors for me are this-is-fine.gif.
helaoban 4y ago
For some (myself included) the high speed and efficiency of proficient modal editing serves as a thinking aid, like sketching with a pencil and eraser. I tend "play" with the code: chopping it up; splitting lines and inserting a bunch of white space; duplicating lines dozens of times to act as placeholder values (e.g filling an array literal); renaming variables across a file many many times before settling on the right name; moving helpers functions to the top, then to the middle, then next to their first invocation etc.... All doable with other editing styles, but at a higher cost, and the cost of manipulation has to be very low in order to reap those meditative qualities. Manipulation far outweighs input. And manipulation is fundamentally thinking, at least for me.
- Aperocky 4y ago
  Great point, /SEARCH_TERM and n is extremely useful for finding stuff and understanding. also when you screw up either because muscle memory went haywire or the logic looks bad then just uuuuu until the status bar (plugin) show no change since last save.
  - p-e-w 4y ago
    As opposed to other editors, which don't have shortcuts for search and undo?
    - rhaway84773 4y ago
      Ctrl/CMD + Z vs u Ctrl/CMD + Y vs r There’s a significant difference in speed. But more importantly, the former requires RSI inducing finger gymnastics, whereas the latter is a tap of a fingertip. The much faster speed but more importantly less complicated chords/key taps in VIM, leads to a qualitatively different editing/reading experience.
  - worksonmine 4y ago
    If your goal is to return to the state where you opened the file ":earlier 10m" might be more useful than spamming u.
- 4y ago
koonsolo 4y ago
I work differently. I mainly read code, and do small manipulations in different places. Reading technical documentation is maybe 5% of what I do. I mainly need to figure out code. So basically it's jumping around, refactor some stuff, and add some stuff. For that, Vim is ideal. Code only flows straight from brain to fingers when it's trivial and boring ;). I use the VSVim plugin in VSCode. I wouldn't necessarily call it a "productivity boost", but more of a convenience or ergonomic solution. The Vim keybindings make it really easy to for example copy something within () and then navigate quickly and paste it somewhere without touching your mouse. But overall I agree, I can probably do the same amount of work without the Vim plugin, it would just make it more inconvenient: more mouse manipulations, ctrl-shift-arrow finger spreadstands to select chucks of text etc.
BrS96bVxXBLzf5B 4y ago
I agree with your point but fwiw when I worked a full time C job doing things with servers running a custom Linux kernel the biggest conveniences were Shift+k over a keyword to open the man page (most of my time was reading docs too!), having some custom scripts that read ctags and could tab-complete keywords from our large codebase and open the files at the right line, and having the same editor on our embedded servers and VMs as on dev machines (and even now that's half of why vim is still my primary). There were people at the company who were more efficient than me using Sublime + mouse, but I was less efficient using Sublime. (but really the biggest reason I use vim as a slow and sloppy typer and not a computer person is, hotkeys make my hands hurt, I've managed to avoid any RSI or pains like this, and I like vim better than vim keybindings in other editors.) other productivity gains not related to typing were the search/replace in vim, embedded terminal, and being in and staying in a terminal made it easier and quicker to switch to scripty things, searching or reformatting files etc
- p-e-w 4y ago
  > Shift+k over a keyword to open the man page Any widely used modern editor/IDE will have plugins to do the same thing. > having some custom scripts that read ctags and could tab-complete keywords from our large codebase Contextual completion as offered by modern IDEs or language servers is vastly superior to Ctags, and you don't have to home-cook anything to get it working. > and having the same editor on our embedded servers and VMs as on dev machines That's what SSHFS is for. No need to limit yourself to whatever happens to be installed on the remote machine. You don't even have to copy config files around.
  - BrS96bVxXBLzf5B 4y ago
    okay? you've pivoted from "not understanding" vim to having an anti-vim boner. other people in the same environement achieved as much or more than me with different tools. and those different tools didn't work for me. that's all that's going on here. (sshfs is not a direct substitute for being able to quickly interact with a remote environment) > having some custom scripts that read ctags and could tab-complete keywords from our large codebase for clarity i meant that I had a completion in the terminal when not in the editor to quickly jump to a tag in a file. `vim -t <keyword>`. i could be in a terminal, execute a remote command on a machine, know what I wanted to look at next and quickly go there without much effort. And again, other people were productive without doing this. these were just my tools and i liked them.
jhoechtl 4y ago
Only tangentially touching your points, my take on Vim or modal editing in general is the following: When I edit existing text (program code, prose) a modal editor shines. I am mostly in command mode and re-arrange text or re-factor code from here to there. When I am _creating_ text, for me a modal type editor is a hindrance. Agreed, I should probably be most of the time in insert mode yet in practice I find myself switching between insert mode and command mode all the time. For what reasons ever this switching never made it into "muscle memory" and disrupts my workflow. For that reasons I am an avid user of both Vim and Emacs.
doix 4y ago
> Is this really unusual? How do people operate for whom Vim gives a productivity boost? Does code just flow from their brains into their fingers? I don't get it. I am very bad at keeping all that stuff in my head at once. I need to get things out of my head onto the screen as fast as possible, so that I can then think about the "next step". Then I need to be able to quickly refer back to many places quickly and switch back and forth between different places in the codebase. For example, as soon as I think of a corner case, I'll try to handle it immediately in an if statement or something. Then it's there, in the code. Maybe it stays in the final version, maybe I end up with 10 if statements and need to refactor everything. But it's much easier for me to do that when everything is written down in the code rather than trying to do it all in my head. If I typed at 15 WPM, I'd probably be easier to just reason about it in my head, because by the time I finished typing, I would have forgotten what I was thinking about. I'm sure these things cause a feedback loop of sorts. Because I know I can get stuff out of my head quickly, I don't bother training myself to get better at storing more in my head at once. So I get worse and the solution is just to edit text faster. Similarly, I suspect since you can keep everything in your head, there's no incentive to get faster at editing text. And if a problem is "harder" the solution is to get better at keeping stuff in your head. I don't think there is a right or wrong answer. I think exposing people to both sides is important, so they can find what works for them.
jcalvinowens 4y ago
I love vim. I've been using it for almost 20 years now. I agree with you about code entry speed, that's not the point. I think the easiest way to put it is that vim is 0% task loading. I never have to expend any energy dealing with it, making it do something I want, finding some button that moved around, etc. Vim just works: in almost two decades, I have never once encountered a single bug or change in behavior that I found irritating. Seriously, never. I just write code. 99% of the code I have written both personally and professionally in my lifetime was written in vim. That's the other win for me: all that muscle memory is still beneficial, now and forever. Its a much more universal tool than any IDE.
flohofwoe 4y ago
I fully agree. Yet I still learned the vi input model because pretty much every text editor on every platform supports it one way or another, and a cross-editor / cross-platform input model makes it a no-brainer to switch editors (which I do all the time, e.g. using vim for quick edits on the command line, and a 'proper' IDE for coding, where the IDE also changes (VStudio, Xcode, VSCode) depending on platform or task at hand. And while typing speed doesn't matter much for productivity, "muscle memory" does for "staying in the flow".
alwillis 4y ago
> Simply put, text manipulation is not at all a productivity bottleneck for me. I need much more time for thinking about code than I need for writing it. For simple things, there's no perceived bottleneck in any editor… but not everything is simple. The productivity gains come from being able to make complex changes to documents using just normal mode and ex commands, which would normally require macros, scripts or plugins in other editors. For example, this 12 year-old video by Derek Wyatt [1] demonstrates extracting the text from a XML representation of a mind map and turning it into a hierarchical, bulleted list using Vim’s search and replace commands which support regular expressions. Attempting to do the same thing in Notepad for example might take you 15-20 minutes. He has a series of these videos, some of them jaw-dropping showing the power and brevity of using Vim for non-trivial editing and data extraction tasks. And remember—this is Vim from 12 years ago with zero plugins. > Does code just flow from their brains into their fingers? I don't get it. There's a reason why the subtitle for Drew Neil's book Practical Vim is "Edit Text at the Speed of Thought" [2]. It's probably the best book on Vim that illuminates the power and efficiency of Vim and why it matters. One you attain a level of proficiency with Vim, as you think about what to do next, your fingers hit the right keys and without thinking about it, the change is done. An identifier for a constant needs to be all caps? Say the cursor is at the end of the line and the identifier is at the start of the line and I'm in insert mode. 1. Press Escape (enters normal mode) 2. Press '0' (motion for jump to first character of the line) 3. Press control-v (enter visual block mode) 4. Press 'e' (move the cursor to the end of the word while highlighting the word) 5. Press '~' (switches the case of the highlighted characters) There's no reaching for the mouse or moving your hand towards the trackpad from the keyboard. It may not seem like much, but for experienced Vim users, an operation like this is a second nature, muscle memory thing that takes about a second to do. There's no break in focus or concentration and you're off doing the next thing. That's where you save time and editing becomes more efficient. And while there are dozens of these types of simple edits that second nature to Vim users, doing more sophisticated changes can be just as efficient. [1]: https://vimeo.com/user1690209 https://vimeo.com/user1690209 [2]: https://pragprog.com/titles/dnvim2/practical-vim-second-edition/ https://pragprog.com/titles/dnvim2/practical-vim-second-edit...
- Zacharias030 4y ago
  I have mapped esc+hjkl to arrow keys system-wide and moved esc to capslock, which is a already a game changer. The respect for vim and especially vim keybindings is definitely there, I use it for editing bashrc‘s or similar or inspecting stuff in the terminal, but what do you recommend to get over the hump of learning it better such that e.g. vimbindings in vscode could replace the standard? For code, I use vscode currently, so your example would be: * cmd capslock h (to go to the beginning of the line) * alt capslock l (to move right to the first word and off the whitespace) * cmd d (to highlight the word und the cursor) * F2 to rename the symbol codebase-wide or cmd shift g to select all occurrences in the file * retype the word in allcaps (enter if F2 was used)
jatins 4y ago
I'll tell you my motivations to switch to Vim. My wrists. All that typing in 20s finally caught up and I have been having recurring wrist pain. Keeping fingers near the home row as Vim keybindings encourage and avoiding jumping around on keyboard in one way to avoid wrist strains and something I'd recommend people to start doing earlier rather that later.
jiki 4y ago
Same here. My productivity gain mainly comes from my brain, not how fast I can type.
throwaway_au_1 4y ago
It sometimes seems like a lot of the Vim, ew crowd think that the sole reason for using Vim is gaining some kind of god-like ability to physically pump out and manipulate characters. Sure, maybe that's possible. For me, it's about being efficient with my keystrokes. Standard shortcuts (Ctrl+_) are pretty unpleasant for my hands - saying this having already mapped CAPS_LOCK to LEFT_CONTROL (and LEFT_CONTROL to ENTER). I like running commands using sequences of letters - it just feels physically easier to me than sequences of multi-key-presses (e.g. Ctrl+Shift+T). That Vim has other smarts around that is just a perk. Editing text using Vim, once you've built the muscle memory, really feels super natural and effortless. I really hate reaching for the mouse; it just irks me in a way that's hard to describe. Similarly, editing code without Vim feels tedious in a similar way. Imagine scrolling a long article by pressing the down arrow over and over, or clicking the down button at the bottom of the scroll bar. Another complaint I see is that remembering the commands is too hard an ask. I moved from QWERTY to Workman at the same time that I was learning Vim and it was interesting because I learned that I -- and probably most people, but I'm speculating -- don't associate commands or actions with letters after they're initially learned. It's all muscle memory, just particular movements of select fingers. The Vim stuff you use day-in-day-out just sticks in your brain and you don't think about anymore than you think about which fingers to activate to type words. Of course, some people probably just prefer to edit text like they do in almost all other text-editing contexts. They can already edit text; without some kind of perceived extra value, there's no motivation to change, or seemingly even try to understand an alternative. For me, it's the pleasure of feeling efficient and doing dev pain-free.
- fileeditview 4y ago
  Yep there are many more reasons than "typing fast" for using Vim. For me the main motivator to dive into Vim was to not use the mouse at all because it constantly gave me RSI. It worked great. I never again had RSI since I switched to Vim for all my coding.
  - ErikCorry 4y ago
    I think part of the benefit of vim for RSI is that there's not much chording - pressing two keys at once. When not using vim you often need control characters on the left hand. Ctrl-C Ctrl-V Ctrl-X Ctrl-A are all on the left. Also, for bash, Ctrl-R and Ctrl-E. I've been training myself to use the right ctrl key for all these, because for some reason I was chording with the left hand. I've also tried to learn to use caps lock for all-caps, but with less success.
mrjin 4y ago
I guess it might be because the nature of your work. When I started as a SE over a decade ago, my job was really just writing code according to the specs. Typing speed was important as I wrote over 100k lines of code in the very first year. But less and less code I wrote after that. Once I spent around 6 months meeting CEO daily just to figure out what was wrong with something screwed pretty badly by someone with a fancy big title. Eventually the code I changed to fix those problems were less than 30 lines. That was extreme, but on average, I hardly write more than 100 lines of code per day just like you. Typing was no more an issue for a very long time.
PurpleRamen 4y ago
> When I "program", 95% of what I do is read documentation and other technical resources That's very off from my work. For me, it's the opposite: 95% is writing code, navigating code, testing code or doing stuff in the shell. Reading documentation usually makes only a small amount. And even then, writing notes makes a good part of it too. > conceptualize what I want to happen, and construct the corresponding logic flow, while trying to anticipate potential problems and corner cases. I can also do that while typing. Mindgears are no reason to stop typing.
DennisP 4y ago
It was a huge productivity boost for me, because when text editing was tedious, I would lose my flow, get bored and annoyed, and start goofing off.
stcroixx 4y ago
Agree so much. It’s such a tiny fraction of the time spent for me no amount of optimization would affect the overall timeline.
jerf 4y ago
"If Vim magically tripled the speed at which I'm able to edit text, I doubt it would have a noticeable impact on my overall productivity." It's an Amdahl's law thing. Even if you drop my typing time down to zero, it wouldn't affect much. That said, multiplying my typing time by 10 would be a hit. I consider being bottlenecked on my raw ability to type to be a huge red flag. I'm doing something wrong unless I have a very specific reason to be so bottlenecked, like I'm momentarily just doing data entry with no ability to simplify the process. (Unusual, but it does happen; for a micro example, typing out all of some enumeration's value can bottleneck on raw typing speed if there's more than a couple of them and I happen to be able to instantly and correctly name them all.) Must be missing an abstraction or something.
gmadsen 4y ago
10k lines is still 10k lines. What I like about vim is that it mimics how i think about code, its the closest thing to a brain interface that an editor can be.
zokier 4y ago
Fast typing speed and efficient editor practice are transformative; when human-computer interface becomes frictionless you unlock notation as a tool of thought, and really be able to use the computer to design your programs instead of doing design first in your head/pen-and-paper/whiteboard and then transcribing near-final code to computer. Or at least that is the idea; I'm not 100% certain if it is not just pipedream for majority of us.
goodpoint 4y ago
> text manipulation is not at all a productivity bottleneck for me No, but the benefit is in the mindset encouraged by Vim, especially around modal editing.
jononomo 4y ago
"Does code just flow from their brains into their fingers?" Honestly, it does feel that way sometimes. You move so much faster and with so much more efficiency and power that you can just think at a higher level while you're coding.
rewgs 4y ago
It’s flow state/reducing cognitive load, not just literal typing speed. I know that might sound insane —- I was extremely weary of such claims for a long time and thought vim was stupid —- but after getting over the “hump,” I get it and absolutely can’t go back.
wruza 4y ago
read documentation and other technical resources, conceptualize what I want to happen, and construct the corresponding logic flow, while trying to anticipate potential problems and corner cases. In other words, most of what I do doesn't involve touching the keyboard at all. In my case, this often creates an elegant and conceptual code that doesn’t match expectations or even reality. Reminds me these meetings when someone e.g. says “no-brainer, there’s API for that” and goes on with requirements, schedules and administrative tasks without checking first if it’s hooks, streaming, polling with a rate limiter, or a non-idempotent email-like protocol with a completely undocumented bullshit in its payload section. The correct remark is “hold your horses”. More than half of my work (strange corners of fintech) is checking, testing, prototyping, fail-refine cycles, unrealistic expectation reports. Not only APIs, also hw, niche software, reverse engineering, a little bit of everything. 80% of it goes straight into the “Attic” repo after few hours. I have to type an unelegant and unconceptual code fast and reshape it at the speed of thought about a realtime problem, there’s no time for clever design if a business-critical decision or a paper-heavy process depend on these experiments. Using a boring editor feels like you want to quickly visit a few places to see if they are good enough, but they are all in different cities, so you start to forget details while you drive. And relying on a documentation is like buying a house by pictures alone. For me the structure comes from the actual code, after I can extract its true shape, after the requirements got satisfied in a fully functional prototype, which is also a sort of a knowledge base for a project. I’m able to plan it in advance, but only with 20% probability and 80% of unnecessary work.
martindbp 4y ago
> Simply put, text manipulation is not at all a productivity bottleneck for me I once believed this and this comment could have been written by me verbatim. But I decided to seriously give vim a try and I'm still very happy 8 years later. I don't know for sure that vim makes me a better programmer, but going from vim to another editor is a bit like going from your large desktop screen to a 13" laptop working at a café. I can do the work but it's just slower and not as enjoyable. Maybe it's not so much vim specifically, although I enjoy the modal editing part, but just 100% investing in a single editor and getting really good at navigating and editing code with it. It's always fast and responsive and always available. Before vim I used different editors for different jobs, Emacs, BlueJ, Eclipse, Visual Studio, Sublime, XCode etc and I never truly invested in any of them. Once you make a decision to just use the one editor, it's a powerful thing.
triceratops 4y ago
Or, as Steve Yegge put it, most programmers are CPU-bound rather than I/O bound.
bostik 4y ago
> Is this really unusual? How do people operate for whom Vim gives a productivity boost? Don't think of vim as a magic totem of productivity. You should think of it as a largely distraction-free editor. No messing about with a mouse. No GUI to get in the way of your thoughts. Loads up immediately, and works the same way in any system, local or remote.[ß] So it's less to do with speed of writing, and much (much!) more about maintaining focus. ß: not really true, any long-time user will have their own customisations they rely on, but the basic commands are always the same.
palata 4y ago
I don't think I'm more productive than non-vim users, it's just my preference. To the point where it's actually painful to use an editor that doesn't support the vim bindings. I like not having to use the mouse, that's more ergonomic for me. Some people have an ergonomic mouse, I just avoid using it. Different solution, not necessarily better or worse.
gorgoiler 4y ago
What you describe feels very true for constructing a green diff containing lots of new code being added to a code base. Being able to juggle text really comes into its own when you now have to move it around from one module into many, appease the linters, search-for then factor-out a common pattern, or rewrite your idea in place without breaking it. These are all things we do to take code from the “it works” stage to the “it’s correct” stage, namely self documenting modular code that is human as well as machine readable. Vim makes light work of the back breaking chores involved with code gardening, which indeed bears little resemblance to programming.
JimBlackwood 4y ago
I doubt Vim helps my productivity. At least, I’m sure if I dropped vim I would be learn to be just as fast in whatever I ended up using. It’s just the ergonomics and easy customizability. Keybindings are in all editors, but in vim I don’t have to press all buttons at once. Just: “space”. Walk to the coffee machine. “g”. Get interrupted. “c” - there opens my git commit window. This feels so infinitely much nicer than any other keybinding system I have used. I always struggle going back to anything else. Next to that, the way the config just works. Just a file I can edit. Vim doesn’t work wonders, it’s just a preference.
camgunz 4y ago
(Sorry late to the game) A friend suggested this to me a while back so I tried a couple IDEs, and it didn't really do it for me. Mostly I think this for three reasons: 1. IDEs don't offer features I need. I don't often need to do a big rename (and if I do, sed and grep have me covered) or generate getters/setters, or what have you. 2. Cool stuff happens outside IDEs. There are tools that generate docs for APIs or even APIs themselves. There are tools that generate clients for APIs. There are tools to build apps using formal techniques (think Jason Donenfeld's work on WireGuard here). IDEs are behind here. 3. For "reasons", I had to implement a circumspect version of DBT in a few days, roughly 1300 LOC. Doing this with Vim was hard enough, but doing this with an IDE would've been impossible because while they help with some of the drudgery of the structure, they can't implement a structure itself, and they can't help me wrangle the raw code. > Does code just flow from their brains into their fingers? I don't get it. It sounds ridiculous, but yeah, more or less. I learn and assess by doing, so mostly I jam things out at 140 wpm, see if it's good, if not do it again. And over a career of doing this I have to do things over less and less, and when I do I get both an implementation and a pretty good empirical defense of it at the end.
rhaway84773 4y ago
Vim is fantastic for reading text. There are so many good commands that make it trivial to move around your code incredibly easily, and also make it easier to read (for example, a 2 key chord to position the line under your current cursor to the top/middle/bottom of your viewport). Even better, unlike most IDEs, the overwhelming majority of your screen is devoted to just the text. There are no toolbars, no sidebars, not even a menu bar. Vim (and similar terminal based editors) are the original focus mode text viewers/editors. Finally, the VIM chords become natural in a way keyboard shortcuts don’t. Part of the reason is that with the VIM normal mode, you have access to significantly more keys with which to form shortcuts, whereas most other editors use number and letter keys for typing text, so shortcuts become increasingly convoluted combinations of modifier keys. Everything about VIM is optimized for reading text, then editing text and only after that inserting text. Inserting text is a special mode in VIM, whereas the default normal mode is for reading. So VIM is a highly optimized tool for the workflow you described.

by p-e-w 4y ago

Panzer04 4y ago

I think it's rarely a productivity bottleneck, but that doesn't mean that Vim keybindings and navigation aren't superior in the vast majority of cases to what most people are doing - which is scrolling, mousing about, etc. Vim keybindings significantly accelerate the editing and browsing of existing code in-editor. It also has the convenience of being a fairly common set of keybindings in editors nowadays, as many have an extension that gives Vim keybindings without having to go all-in on a CLI-style Vim editor.

p-e-w 4y ago
Every modern code editor has character-, word-, subword-, line-, and page-based navigation, as well as "jump to symbol" functionality. Bookmarks, paragraph navigation, and similar are also very common. I fail to see how Vim is supposed to be superior to that. It has essentially the same navigation features, with different keybindings. And the idea that those different keybindings are somehow "better" is a big [citation needed].
- Panzer04 4y ago
  How common are the keybindings used in existing editors? I must admit I haven't ever really noticed the hotkeys/keybindings in editors - until I started using Vim bindings instead. There's likely a large crossover between people who use a lot of hotkeys and people who look into learning something like Vim. If they change often across editors, it wouldn't surprise me that they aren't often used, so don't get much evangelism compared to Vim (which has been more or less the same for decades) I only use a small subset of Vim's shortcuts - but most text editors I've used I'd imagine don't have the breadth Vim does (or they do a really poor job of documenting it). Can you point out a doc page for some IDE with similar navigation capabilities to Vim?
  - p-e-w 4y ago
    > How common are the keybindings used in existing editors? The whole point of widget toolkits is that the keybindings for input fields are the same everywhere. I use Linux and almost exclusively run GTK-based apps, and every text input across the whole system behaves the exact same way, with consistent keybindings for navigation, undo/redo, copy+paste etc. This is how good UI should work. Platform conventions are important, and it's the job of individual programs to adapt to them – not the other way round. Vim fails big time in this regard. Can you make Firefox's form inputs use Vim keybindings? If not, there's your inconsistency already.
    - deleted 4y ago
      [deleted]
    - xeyownt 4y ago
      > Platform conventions are important, and it's the job of individual programs to adapt to them – not the other way round. Vim fails big time in this regard. Can you make Firefox's form inputs use Vim keybindings? If not, there's your inconsistency already. I disagree with that. And the world doesn't have to be perfect. If you use Vim and you like it (it takes LOT of effort), you will adapt the platform to the Vim ways whenever possible. Everytime I encounter something I cannot vim-ize, I'm pissed but I have to put up with it. It's like working with Windows. For the browser, you can use Vim binding for navigation, and edit with Vim. But again, this is not mandatory per se to benefit from Vim as a developer.

Aperocky 4y ago

Do you write config files? Do you copy similar unit test structures? or perhaps have you ever found a mouse/touchpad annoying? If purely going off programming speed, probably won't improve much. Most of the time is spent thinking. But it helps reduce annoyance in many other situations - I'm not annoyed when I think, but I'm annoyed when I have to move the cursor, drag it and do it 10 different times when in vim the same is burned into muscle memory and can be done without any thought process, over some config file that I must edit now but not that often enough that it's worth creating a script or template, and then the same apply to templates as well and all levels of abstraction. An extremely common scenario is to copy the content from one enclosed parentheses and into another, and similar class of problems. With vim it's just a few keystrokes, but without it's lots of cursor and drag. These common scenarios are why people use vim bindings. Oh and I can do all of that in the terminal of a remote machine, which happen to have enough memory to run a massive integration test, and build all things a lot faster.

xeyownt 4y ago

If I would type at 15 WPM, I would be MUCH less productive than I am today for sure. The point of using Vim, is that you boost your keyboard interface to the maximum. Obviously, using Vim, means you touch-type. Also, you don't use the mouse. Basically, using Vim, is like having the brain hard-wired to the computer for every task, not only text edition. Everything you do goes through the keyboard, and you don't have to think about it. You scroll through text, search for it, edit it, open new files, etc. For instance, most of the time I don't use any GUI for Git either. I do everything in the terminal, and only use the GUI for partial commit (ie. select which line to commit). I have dedicated aliases for getting history, etc. Also, when learning Vim, you notice that many (Linux) tools have Vim shortcuts enabled. I discovered many of them by chance, out of the habits of using Vim shortcuts.

p-e-w 4y ago
> Everything you do goes through the keyboard Except web browsing, which is a huge part of software engineering, and which is nearly impossible to do without the mouse because most websites cannot be reasonably navigated with shortcuts alone. So the whole model falls apart, really.
- schoen 4y ago
  Some avid vim users will also use https://vimium.github.io/ https://vimium.github.io/ in their browsers, so they can also browse using the keyboard and vim-like cursor movement commands.
- d4rti 4y ago
  Tridactyl does the job for most websites pretty well as for text heavy sites like documentation it’s very good. https://github.com/tridactyl/tridactyl https://github.com/tridactyl/tridactyl
- ludicast 4y ago
  I don't find myself needing the browser too much when I code. Other than to reload a page if I'm tweaking something on the FE. Not that I know everything, but I view informational browsing as a distraction while programming. The LSP augments most of the knowledge gaps for me. If vim isn't for you that's cool. But I find other editors for me are this-is-fine.gif.

helaoban 4y ago

For some (myself included) the high speed and efficiency of proficient modal editing serves as a thinking aid, like sketching with a pencil and eraser. I tend "play" with the code: chopping it up; splitting lines and inserting a bunch of white space; duplicating lines dozens of times to act as placeholder values (e.g filling an array literal); renaming variables across a file many many times before settling on the right name; moving helpers functions to the top, then to the middle, then next to their first invocation etc.... All doable with other editing styles, but at a higher cost, and the cost of manipulation has to be very low in order to reap those meditative qualities. Manipulation far outweighs input. And manipulation is fundamentally thinking, at least for me.

Aperocky 4y ago
Great point, /SEARCH_TERM and n is extremely useful for finding stuff and understanding. also when you screw up either because muscle memory went haywire or the logic looks bad then just uuuuu until the status bar (plugin) show no change since last save.
- p-e-w 4y ago
  As opposed to other editors, which don't have shortcuts for search and undo?
  - rhaway84773 4y ago
    Ctrl/CMD + Z vs u Ctrl/CMD + Y vs r There’s a significant difference in speed. But more importantly, the former requires RSI inducing finger gymnastics, whereas the latter is a tap of a fingertip. The much faster speed but more importantly less complicated chords/key taps in VIM, leads to a qualitatively different editing/reading experience.
- worksonmine 4y ago
  If your goal is to return to the state where you opened the file ":earlier 10m" might be more useful than spamming u.
4y ago

koonsolo 4y ago

I work differently. I mainly read code, and do small manipulations in different places. Reading technical documentation is maybe 5% of what I do. I mainly need to figure out code. So basically it's jumping around, refactor some stuff, and add some stuff. For that, Vim is ideal. Code only flows straight from brain to fingers when it's trivial and boring ;). I use the VSVim plugin in VSCode. I wouldn't necessarily call it a "productivity boost", but more of a convenience or ergonomic solution. The Vim keybindings make it really easy to for example copy something within () and then navigate quickly and paste it somewhere without touching your mouse. But overall I agree, I can probably do the same amount of work without the Vim plugin, it would just make it more inconvenient: more mouse manipulations, ctrl-shift-arrow finger spreadstands to select chucks of text etc.

BrS96bVxXBLzf5B 4y ago

I agree with your point but fwiw when I worked a full time C job doing things with servers running a custom Linux kernel the biggest conveniences were Shift+k over a keyword to open the man page (most of my time was reading docs too!), having some custom scripts that read ctags and could tab-complete keywords from our large codebase and open the files at the right line, and having the same editor on our embedded servers and VMs as on dev machines (and even now that's half of why vim is still my primary). There were people at the company who were more efficient than me using Sublime + mouse, but I was less efficient using Sublime. (but really the biggest reason I use vim as a slow and sloppy typer and not a computer person is, hotkeys make my hands hurt, I've managed to avoid any RSI or pains like this, and I like vim better than vim keybindings in other editors.) other productivity gains not related to typing were the search/replace in vim, embedded terminal, and being in and staying in a terminal made it easier and quicker to switch to scripty things, searching or reformatting files etc

p-e-w 4y ago
> Shift+k over a keyword to open the man page Any widely used modern editor/IDE will have plugins to do the same thing. > having some custom scripts that read ctags and could tab-complete keywords from our large codebase Contextual completion as offered by modern IDEs or language servers is vastly superior to Ctags, and you don't have to home-cook anything to get it working. > and having the same editor on our embedded servers and VMs as on dev machines That's what SSHFS is for. No need to limit yourself to whatever happens to be installed on the remote machine. You don't even have to copy config files around.
- BrS96bVxXBLzf5B 4y ago
  okay? you've pivoted from "not understanding" vim to having an anti-vim boner. other people in the same environement achieved as much or more than me with different tools. and those different tools didn't work for me. that's all that's going on here. (sshfs is not a direct substitute for being able to quickly interact with a remote environment) > having some custom scripts that read ctags and could tab-complete keywords from our large codebase for clarity i meant that I had a completion in the terminal when not in the editor to quickly jump to a tag in a file. `vim -t <keyword>`. i could be in a terminal, execute a remote command on a machine, know what I wanted to look at next and quickly go there without much effort. And again, other people were productive without doing this. these were just my tools and i liked them.

jhoechtl 4y ago

Only tangentially touching your points, my take on Vim or modal editing in general is the following: When I edit existing text (program code, prose) a modal editor shines. I am mostly in command mode and re-arrange text or re-factor code from here to there. When I am _creating_ text, for me a modal type editor is a hindrance. Agreed, I should probably be most of the time in insert mode yet in practice I find myself switching between insert mode and command mode all the time. For what reasons ever this switching never made it into "muscle memory" and disrupts my workflow. For that reasons I am an avid user of both Vim and Emacs.

doix 4y ago

> Is this really unusual? How do people operate for whom Vim gives a productivity boost? Does code just flow from their brains into their fingers? I don't get it. I am very bad at keeping all that stuff in my head at once. I need to get things out of my head onto the screen as fast as possible, so that I can then think about the "next step". Then I need to be able to quickly refer back to many places quickly and switch back and forth between different places in the codebase. For example, as soon as I think of a corner case, I'll try to handle it immediately in an if statement or something. Then it's there, in the code. Maybe it stays in the final version, maybe I end up with 10 if statements and need to refactor everything. But it's much easier for me to do that when everything is written down in the code rather than trying to do it all in my head. If I typed at 15 WPM, I'd probably be easier to just reason about it in my head, because by the time I finished typing, I would have forgotten what I was thinking about. I'm sure these things cause a feedback loop of sorts. Because I know I can get stuff out of my head quickly, I don't bother training myself to get better at storing more in my head at once. So I get worse and the solution is just to edit text faster. Similarly, I suspect since you can keep everything in your head, there's no incentive to get faster at editing text. And if a problem is "harder" the solution is to get better at keeping stuff in your head. I don't think there is a right or wrong answer. I think exposing people to both sides is important, so they can find what works for them.

jcalvinowens 4y ago

I love vim. I've been using it for almost 20 years now. I agree with you about code entry speed, that's not the point. I think the easiest way to put it is that vim is 0% task loading. I never have to expend any energy dealing with it, making it do something I want, finding some button that moved around, etc. Vim just works: in almost two decades, I have never once encountered a single bug or change in behavior that I found irritating. Seriously, never. I just write code. 99% of the code I have written both personally and professionally in my lifetime was written in vim. That's the other win for me: all that muscle memory is still beneficial, now and forever. Its a much more universal tool than any IDE.

flohofwoe 4y ago

I fully agree. Yet I still learned the vi input model because pretty much every text editor on every platform supports it one way or another, and a cross-editor / cross-platform input model makes it a no-brainer to switch editors (which I do all the time, e.g. using vim for quick edits on the command line, and a 'proper' IDE for coding, where the IDE also changes (VStudio, Xcode, VSCode) depending on platform or task at hand. And while typing speed doesn't matter much for productivity, "muscle memory" does for "staying in the flow".

alwillis 4y ago

> Simply put, text manipulation is not at all a productivity bottleneck for me. I need much more time for thinking about code than I need for writing it. For simple things, there's no perceived bottleneck in any editor… but not everything is simple. The productivity gains come from being able to make complex changes to documents using just normal mode and ex commands, which would normally require macros, scripts or plugins in other editors. For example, this 12 year-old video by Derek Wyatt [1] demonstrates extracting the text from a XML representation of a mind map and turning it into a hierarchical, bulleted list using Vim’s search and replace commands which support regular expressions. Attempting to do the same thing in Notepad for example might take you 15-20 minutes. He has a series of these videos, some of them jaw-dropping showing the power and brevity of using Vim for non-trivial editing and data extraction tasks. And remember—this is Vim from 12 years ago with zero plugins. > Does code just flow from their brains into their fingers? I don't get it. There's a reason why the subtitle for Drew Neil's book Practical Vim is "Edit Text at the Speed of Thought" [2]. It's probably the best book on Vim that illuminates the power and efficiency of Vim and why it matters. One you attain a level of proficiency with Vim, as you think about what to do next, your fingers hit the right keys and without thinking about it, the change is done. An identifier for a constant needs to be all caps? Say the cursor is at the end of the line and the identifier is at the start of the line and I'm in insert mode. 1. Press Escape (enters normal mode) 2. Press '0' (motion for jump to first character of the line) 3. Press control-v (enter visual block mode) 4. Press 'e' (move the cursor to the end of the word while highlighting the word) 5. Press '~' (switches the case of the highlighted characters) There's no reaching for the mouse or moving your hand towards the trackpad from the keyboard. It may not seem like much, but for experienced Vim users, an operation like this is a second nature, muscle memory thing that takes about a second to do. There's no break in focus or concentration and you're off doing the next thing. That's where you save time and editing becomes more efficient. And while there are dozens of these types of simple edits that second nature to Vim users, doing more sophisticated changes can be just as efficient. [1]: https://vimeo.com/user1690209 https://vimeo.com/user1690209 [2]: https://pragprog.com/titles/dnvim2/practical-vim-second-edition/ https://pragprog.com/titles/dnvim2/practical-vim-second-edit...

Zacharias030 4y ago
I have mapped esc+hjkl to arrow keys system-wide and moved esc to capslock, which is a already a game changer. The respect for vim and especially vim keybindings is definitely there, I use it for editing bashrc‘s or similar or inspecting stuff in the terminal, but what do you recommend to get over the hump of learning it better such that e.g. vimbindings in vscode could replace the standard? For code, I use vscode currently, so your example would be: * cmd capslock h (to go to the beginning of the line) * alt capslock l (to move right to the first word and off the whitespace) * cmd d (to highlight the word und the cursor) * F2 to rename the symbol codebase-wide or cmd shift g to select all occurrences in the file * retype the word in allcaps (enter if F2 was used)

jatins 4y ago

I'll tell you my motivations to switch to Vim. My wrists. All that typing in 20s finally caught up and I have been having recurring wrist pain. Keeping fingers near the home row as Vim keybindings encourage and avoiding jumping around on keyboard in one way to avoid wrist strains and something I'd recommend people to start doing earlier rather that later.

jiki 4y ago

Same here. My productivity gain mainly comes from my brain, not how fast I can type.

throwaway_au_1 4y ago

It sometimes seems like a lot of the Vim, ew crowd think that the sole reason for using Vim is gaining some kind of god-like ability to physically pump out and manipulate characters. Sure, maybe that's possible. For me, it's about being efficient with my keystrokes. Standard shortcuts (Ctrl+_) are pretty unpleasant for my hands - saying this having already mapped CAPS_LOCK to LEFT_CONTROL (and LEFT_CONTROL to ENTER). I like running commands using sequences of letters - it just feels physically easier to me than sequences of multi-key-presses (e.g. Ctrl+Shift+T). That Vim has other smarts around that is just a perk. Editing text using Vim, once you've built the muscle memory, really feels super natural and effortless. I really hate reaching for the mouse; it just irks me in a way that's hard to describe. Similarly, editing code without Vim feels tedious in a similar way. Imagine scrolling a long article by pressing the down arrow over and over, or clicking the down button at the bottom of the scroll bar. Another complaint I see is that remembering the commands is too hard an ask. I moved from QWERTY to Workman at the same time that I was learning Vim and it was interesting because I learned that I -- and probably most people, but I'm speculating -- don't associate commands or actions with letters after they're initially learned. It's all muscle memory, just particular movements of select fingers. The Vim stuff you use day-in-day-out just sticks in your brain and you don't think about anymore than you think about which fingers to activate to type words. Of course, some people probably just prefer to edit text like they do in almost all other text-editing contexts. They can already edit text; without some kind of perceived extra value, there's no motivation to change, or seemingly even try to understand an alternative. For me, it's the pleasure of feeling efficient and doing dev pain-free.

fileeditview 4y ago
Yep there are many more reasons than "typing fast" for using Vim. For me the main motivator to dive into Vim was to not use the mouse at all because it constantly gave me RSI. It worked great. I never again had RSI since I switched to Vim for all my coding.
- ErikCorry 4y ago
  I think part of the benefit of vim for RSI is that there's not much chording - pressing two keys at once. When not using vim you often need control characters on the left hand. Ctrl-C Ctrl-V Ctrl-X Ctrl-A are all on the left. Also, for bash, Ctrl-R and Ctrl-E. I've been training myself to use the right ctrl key for all these, because for some reason I was chording with the left hand. I've also tried to learn to use caps lock for all-caps, but with less success.

mrjin 4y ago

I guess it might be because the nature of your work. When I started as a SE over a decade ago, my job was really just writing code according to the specs. Typing speed was important as I wrote over 100k lines of code in the very first year. But less and less code I wrote after that. Once I spent around 6 months meeting CEO daily just to figure out what was wrong with something screwed pretty badly by someone with a fancy big title. Eventually the code I changed to fix those problems were less than 30 lines. That was extreme, but on average, I hardly write more than 100 lines of code per day just like you. Typing was no more an issue for a very long time.

PurpleRamen 4y ago

> When I "program", 95% of what I do is read documentation and other technical resources That's very off from my work. For me, it's the opposite: 95% is writing code, navigating code, testing code or doing stuff in the shell. Reading documentation usually makes only a small amount. And even then, writing notes makes a good part of it too. > conceptualize what I want to happen, and construct the corresponding logic flow, while trying to anticipate potential problems and corner cases. I can also do that while typing. Mindgears are no reason to stop typing.

DennisP 4y ago

It was a huge productivity boost for me, because when text editing was tedious, I would lose my flow, get bored and annoyed, and start goofing off.

stcroixx 4y ago

Agree so much. It’s such a tiny fraction of the time spent for me no amount of optimization would affect the overall timeline.

jerf 4y ago

"If Vim magically tripled the speed at which I'm able to edit text, I doubt it would have a noticeable impact on my overall productivity." It's an Amdahl's law thing. Even if you drop my typing time down to zero, it wouldn't affect much. That said, multiplying my typing time by 10 would be a hit. I consider being bottlenecked on my raw ability to type to be a huge red flag. I'm doing something wrong unless I have a very specific reason to be so bottlenecked, like I'm momentarily just doing data entry with no ability to simplify the process. (Unusual, but it does happen; for a micro example, typing out all of some enumeration's value can bottleneck on raw typing speed if there's more than a couple of them and I happen to be able to instantly and correctly name them all.) Must be missing an abstraction or something.

gmadsen 4y ago

10k lines is still 10k lines. What I like about vim is that it mimics how i think about code, its the closest thing to a brain interface that an editor can be.

zokier 4y ago

Fast typing speed and efficient editor practice are transformative; when human-computer interface becomes frictionless you unlock notation as a tool of thought, and really be able to use the computer to design your programs instead of doing design first in your head/pen-and-paper/whiteboard and then transcribing near-final code to computer. Or at least that is the idea; I'm not 100% certain if it is not just pipedream for majority of us.

goodpoint 4y ago

> text manipulation is not at all a productivity bottleneck for me No, but the benefit is in the mindset encouraged by Vim, especially around modal editing.

jononomo 4y ago

"Does code just flow from their brains into their fingers?" Honestly, it does feel that way sometimes. You move so much faster and with so much more efficiency and power that you can just think at a higher level while you're coding.

rewgs 4y ago

It’s flow state/reducing cognitive load, not just literal typing speed. I know that might sound insane —- I was extremely weary of such claims for a long time and thought vim was stupid —- but after getting over the “hump,” I get it and absolutely can’t go back.

wruza 4y ago

read documentation and other technical resources, conceptualize what I want to happen, and construct the corresponding logic flow, while trying to anticipate potential problems and corner cases. In other words, most of what I do doesn't involve touching the keyboard at all. In my case, this often creates an elegant and conceptual code that doesn’t match expectations or even reality. Reminds me these meetings when someone e.g. says “no-brainer, there’s API for that” and goes on with requirements, schedules and administrative tasks without checking first if it’s hooks, streaming, polling with a rate limiter, or a non-idempotent email-like protocol with a completely undocumented bullshit in its payload section. The correct remark is “hold your horses”. More than half of my work (strange corners of fintech) is checking, testing, prototyping, fail-refine cycles, unrealistic expectation reports. Not only APIs, also hw, niche software, reverse engineering, a little bit of everything. 80% of it goes straight into the “Attic” repo after few hours. I have to type an unelegant and unconceptual code fast and reshape it at the speed of thought about a realtime problem, there’s no time for clever design if a business-critical decision or a paper-heavy process depend on these experiments. Using a boring editor feels like you want to quickly visit a few places to see if they are good enough, but they are all in different cities, so you start to forget details while you drive. And relying on a documentation is like buying a house by pictures alone. For me the structure comes from the actual code, after I can extract its true shape, after the requirements got satisfied in a fully functional prototype, which is also a sort of a knowledge base for a project. I’m able to plan it in advance, but only with 20% probability and 80% of unnecessary work.

martindbp 4y ago

> Simply put, text manipulation is not at all a productivity bottleneck for me I once believed this and this comment could have been written by me verbatim. But I decided to seriously give vim a try and I'm still very happy 8 years later. I don't know for sure that vim makes me a better programmer, but going from vim to another editor is a bit like going from your large desktop screen to a 13" laptop working at a café. I can do the work but it's just slower and not as enjoyable. Maybe it's not so much vim specifically, although I enjoy the modal editing part, but just 100% investing in a single editor and getting really good at navigating and editing code with it. It's always fast and responsive and always available. Before vim I used different editors for different jobs, Emacs, BlueJ, Eclipse, Visual Studio, Sublime, XCode etc and I never truly invested in any of them. Once you make a decision to just use the one editor, it's a powerful thing.

triceratops 4y ago

Or, as Steve Yegge put it, most programmers are CPU-bound rather than I/O bound.

bostik 4y ago

> Is this really unusual? How do people operate for whom Vim gives a productivity boost? Don't think of vim as a magic totem of productivity. You should think of it as a largely distraction-free editor. No messing about with a mouse. No GUI to get in the way of your thoughts. Loads up immediately, and works the same way in any system, local or remote.[ß] So it's less to do with speed of writing, and much (much!) more about maintaining focus. ß: not really true, any long-time user will have their own customisations they rely on, but the basic commands are always the same.

palata 4y ago

I don't think I'm more productive than non-vim users, it's just my preference. To the point where it's actually painful to use an editor that doesn't support the vim bindings. I like not having to use the mouse, that's more ergonomic for me. Some people have an ergonomic mouse, I just avoid using it. Different solution, not necessarily better or worse.

gorgoiler 4y ago

What you describe feels very true for constructing a green diff containing lots of new code being added to a code base. Being able to juggle text really comes into its own when you now have to move it around from one module into many, appease the linters, search-for then factor-out a common pattern, or rewrite your idea in place without breaking it. These are all things we do to take code from the “it works” stage to the “it’s correct” stage, namely self documenting modular code that is human as well as machine readable. Vim makes light work of the back breaking chores involved with code gardening, which indeed bears little resemblance to programming.

JimBlackwood 4y ago

I doubt Vim helps my productivity. At least, I’m sure if I dropped vim I would be learn to be just as fast in whatever I ended up using. It’s just the ergonomics and easy customizability. Keybindings are in all editors, but in vim I don’t have to press all buttons at once. Just: “space”. Walk to the coffee machine. “g”. Get interrupted. “c” - there opens my git commit window. This feels so infinitely much nicer than any other keybinding system I have used. I always struggle going back to anything else. Next to that, the way the config just works. Just a file I can edit. Vim doesn’t work wonders, it’s just a preference.

camgunz 4y ago

(Sorry late to the game) A friend suggested this to me a while back so I tried a couple IDEs, and it didn't really do it for me. Mostly I think this for three reasons: 1. IDEs don't offer features I need. I don't often need to do a big rename (and if I do, sed and grep have me covered) or generate getters/setters, or what have you. 2. Cool stuff happens outside IDEs. There are tools that generate docs for APIs or even APIs themselves. There are tools that generate clients for APIs. There are tools to build apps using formal techniques (think Jason Donenfeld's work on WireGuard here). IDEs are behind here. 3. For "reasons", I had to implement a circumspect version of DBT in a few days, roughly 1300 LOC. Doing this with Vim was hard enough, but doing this with an IDE would've been impossible because while they help with some of the drudgery of the structure, they can't implement a structure itself, and they can't help me wrangle the raw code. > Does code just flow from their brains into their fingers? I don't get it. It sounds ridiculous, but yeah, more or less. I learn and assess by doing, so mostly I jam things out at 140 wpm, see if it's good, if not do it again. And over a career of doing this I have to do things over less and less, and when I do I get both an implementation and a pretty good empirical defense of it at the end.

rhaway84773 4y ago

Vim is fantastic for reading text. There are so many good commands that make it trivial to move around your code incredibly easily, and also make it easier to read (for example, a 2 key chord to position the line under your current cursor to the top/middle/bottom of your viewport). Even better, unlike most IDEs, the overwhelming majority of your screen is devoted to just the text. There are no toolbars, no sidebars, not even a menu bar. Vim (and similar terminal based editors) are the original focus mode text viewers/editors. Finally, the VIM chords become natural in a way keyboard shortcuts don’t. Part of the reason is that with the VIM normal mode, you have access to significantly more keys with which to form shortcuts, whereas most other editors use number and letter keys for typing text, so shortcuts become increasingly convoluted combinations of modifier keys. Everything about VIM is optimized for reading text, then editing text and only after that inserting text. Inserting text is a special mode in VIM, whereas the default normal mode is for reading. So VIM is a highly optimized tool for the workflow you described.