4 ms·

I very much understand people are different and it seems for some people details like these are important. That said, with the work I do (mostly Java/Kotlin/C#

I very much understand people are different and it seems for some people details like these are important. That said, with the work I do (mostly Java/Kotlin/C# backend and TypeScript frontend) and the way I do it (IDE), if typing speed ever becomes a bottleneck, something has gone horribly wrong somewhere. And since I have went through a number of times earlier in my life where I thought I had to learn vim, I think it can be good to try the other way around and ask everyone who doesn't love their vim setup but feel they have to: Why are you doing all this typing? If you update a variable name or a method signature and the rest of the code doesn't automatically update itself as far as possible, why is this? Why is your (hopefully) modern computer allowed to slack of while you have to think and work hard? Intelligent autocomplete, template insertions and automatic refactoring has been available for a long time now in mainstream languages. If you aren't using it, chances are you are wired really different than me or you are missing out. Edit: but if you love your vim setup, just continue. I love watching people who are good with vim. It is performance art. But I decided it isn't for me, and I personally think for a number of others too, if they had spent a fraction of the time they've spent tweaking their setups on actually learning a real IDE that could have made a bigger difference.

gassiss 3y ago
For me it was never about speed, it’s about comfort. I always unconsciously hated having to reach for the arrow keys all the way to the right of the keyboard to select words and move around.
- marginalia_nu 3y ago
  A generation of Swedish programmers grew up on a cruel and unusual keyboard layout that's like ; is shift + , (1 step right of m) : is shift + . (2 steps right of m) - is where US layout has / _ is where US layout has ? shift + 6 = & shift + 7 = / shift + 8 = ( shift + 9 = ) right alt + 7 = { right alt + 8 = [ right alt + 9 = ] right alt + 0 = } right alt + - = \ I invite anyone to try and press right alt + 7 and right alt + 9 on their keyboard. To make things more awkward, it must be the right alt key, it doesn't work with the left. This torture is every time you make a curly brace with this layout.
  - rho4 3y ago
    Same for German and Swiss layouts *sigh. After many years, I am now capable of typing curly and angular brackets by holding left shift with my small finger, left alt with my left thumb, and the corresponding symbol key with my right little finger, without loosing the ten-finger-stance on the keyboard. (on our keyboards, left shift+alt is an alternative for the right "Alt Gr" key)
    - SebastianKra 3y ago
      If you still can, I highly recommend switching to international. The main benefit is, how much better default keyboard shortcuts in many Apps become. Tab switching with CMD+{} and back/forward CMD+[] can be comfortably executed. There are no more inaccessible shortcuts such as Shift+CMD+? or changing playback speed on Youtube. Specials are somewhat annoying to type with `alt+u aou` and `alt + s`, but nothing I couldn't get used to.
  - awelxtr 3y ago
    Spaniard here. I've done it all my life. Maybe my pain tolerance is way higher? Edit: I don't know what's wrong with pressing several keys at once to do something. It is like complaining that piano has no individual keys for all the possible chords. What's the alternative? Pressing a single key? What would you be doing with the rest of your fingers anyway?
    - marginalia_nu 3y ago
      The problem is that you need to press multiple keys with the same hand. Typically when touch-typing you press modifier keys with the other hand, to avoid having to move the hand in awkward ways, or typing with the left hand on the right side of the keyboard or some other weird solution. On top of that, alt+7 is spectacularly awkward, as you need to curl one finger really aggressively and extend another to reach both keys. Many of these keys are indeed accessible with a single keypress in US QWERTY. That, or a simple shift-combination. They're also much closer to the letter keys across the board.
    - AlbertoGP 3y ago
- nntwozz 3y ago
  I use a southpaw keyboard with arrow keys on the left side. I think it's a great design, it frees up space for the mouse bringing your arms closer together for a more ergonomic position. I'm not necessarily saying it's better but it makes you think about how input design shapes the use of software.
robenkleene 3y ago
I was once IDE-ish, and now Vim-ish, so I think I can answer this a bit. Everything you say is true (I guess except for the typing a lot, I don't find renaming a variable to feel like more typing in an IDE vs. Vim, but you're right that there are some IDE features that make some things easier). - The biggest problem I have with the IDE workflow is I was never able to get it to scale across projects effectively. E.g., lets say I want to make a find and replace for an API change across ten different projects, then run linters and compilation on all of them, and only be notified if there's an error, and otherwise make identical commits to all of the projects? - Another issue, is how easy is it for me to take the problem I'm working on, extract it to a complete different context, and then more quickly iterate on finding a solution? E.g., it's common for me to take what I'm working on, in say JavaScript, that's part of a larger application, and then copy/paste the entire problem into a single file with a `#!/usr/bin/env node` shebang, and then do a 1. edit/save 2. run `./my_script.js` workflow until I find the solution. With IDE's, I've found they often don't like working with single files that aren't part of a particular project. - When tracking down extremely difficult to find bugs, e.g., lets say you have several log files, thousands of lines long, and you want to use CLI tools to do custom analysis looking for patterns (e.g., is there a mismatch in order certain events firing in log files where the bug occurs vs. doesn't?). IDEs don't help much with this. There's a pattern with the above examples that's the main problem I had with IDEs is that they aren't flexible enough to scale to atypical workflows/problems. All of the above examples also leverage the command line, which is clearly a pattern. The CLI is just a useful open-ended tool to help programmatically solve any problem you might be facing. IDEs are great if you're adding a feature to an application, but they're less great if you're looking to adapt your tools to a specialized workflow that's a better fit for the problem at hand. Besides the above examples, I've also encountered code bases too large for JetBrains IDEs (rare, but they're out there), and generally find how slow they are to open windows to be disruptive to achieving flow state (I don't think this is normal, I think I personally experience latency more strongly than most other computer users, but just providing a complete picture). I also don't really find autocomplete very useful, which again is atypical, I use it in CLI-based editors like Vim/Emacs because it's trivial to add it with LSP support today, but would be fine working without it. Again it's about what you value, what I value is being able to adapt my tools to developing a specialized workflow to solve the problem at hand, over the features that IDEs offer.
laserlight 3y ago
> if typing speed ever becomes a bottleneck, something has gone horribly wrong somewhere. I've never understood such reasoning. Typing speed is a bottleneck. It cannot be parallelized with other tasks, and therefore, is on the critical path. Improving typing speed will shorten task duration. What is perhaps meant instead is that typing is not worth improving, because gains wouldn't affect overall task duration significantly. But then, why focus on percentage improvement over task duration? I use a keyboard all day. Any improvement affects my day-to-day quality of life for the rest of my life. Keypresses saved, finger, wrist, arm movements eliminated increases my comfort. Removing frictions in work increases flow.
thom 3y ago
I personally like not having to move around too much, but beyond CapsLock for Ctrl I’ve never stuck with anything fancy. That said, I don’t understand how typing speed doesn’t matter - I agree that’s mostly the case for code, but everything in between, from documentation to Slack chats, I think faster than I type and I’m always open to performance improvements. It’s also great if you can context switch with as little friction as possible so that you can hit the ground running each time. Overall it’s just about actions per second, not actual typing. I agree that IDEs and advanced editors help cut out a lot of stuff (I’ve never understood multiple cursors, for example, because as you say, that’s usually just a structured refactoring). But there are always opportunities to cut down cognitive load or speed up regular tasks. Whether hardware or software, we’re in tech because we believe better tools solve problems better.
ughitsaaron 3y ago
For me, not taking my hands off the keyboard (or more specifically, not touching the mouse) is less about speed, and more that it helps me remain focused on what I’m doing.
gumby 3y ago
> if typing speed ever becomes a bottleneck... The issue isn't really speed, it's moving your hands away from the core of the keyboard. Touch typing means you don't have to think about getting text into your machine (or modifying it) -- it just happens. Having to move your hand away to somewhere else (arrow keys or, shudder a mouse/trackpad) causes a microinterruption in your flow.
graypegg 3y ago
So, I use the Vim layer in IntelliJ. While it’s true that the IDE is doing a little bit of the repetitive typing work, there’s still things that are more comfortable with vim commands. To give an example you mentioned: > Why are you doing all this typing? If you update a variable name or a method signature and the rest of the code doesn't automatically update itself as far as possible, why is this? I use refactoring tools a ton! Rename Symbol works great. I’ll press the IDE combo for Refactor this (C-t) then the vim combo to, for example, add a suffix to the name that’s now highlighted by the IDE (wi SuffixNameHere<CR>) It’s not like it’s hard to do that by clicking the end of the word with the cursor, or moving to it with the arrow keys. But it’s so much more comfy to me, once you have a few movements in your head you can precisely communicate “go THERE” to your editor which is worth it to me. Bonus: @ macros! It’s so useful, even in IDEs, to be able to record (qx) and run (@x) a macro from your keyboard, while typing, if you notice that you’re repeating the same task. An IDE will help with renaming, removing, or re-signaturing… but not with the most annoying work, like numbering things or repeating blocks.

gassiss 3y ago

For me it was never about speed, it’s about comfort. I always unconsciously hated having to reach for the arrow keys all the way to the right of the keyboard to select words and move around.

marginalia_nu 3y ago
A generation of Swedish programmers grew up on a cruel and unusual keyboard layout that's like ; is shift + , (1 step right of m) : is shift + . (2 steps right of m) - is where US layout has / _ is where US layout has ? shift + 6 = & shift + 7 = / shift + 8 = ( shift + 9 = ) right alt + 7 = { right alt + 8 = [ right alt + 9 = ] right alt + 0 = } right alt + - = \ I invite anyone to try and press right alt + 7 and right alt + 9 on their keyboard. To make things more awkward, it must be the right alt key, it doesn't work with the left. This torture is every time you make a curly brace with this layout.
- rho4 3y ago
  Same for German and Swiss layouts *sigh. After many years, I am now capable of typing curly and angular brackets by holding left shift with my small finger, left alt with my left thumb, and the corresponding symbol key with my right little finger, without loosing the ten-finger-stance on the keyboard. (on our keyboards, left shift+alt is an alternative for the right "Alt Gr" key)
  - SebastianKra 3y ago
    If you still can, I highly recommend switching to international. The main benefit is, how much better default keyboard shortcuts in many Apps become. Tab switching with CMD+{} and back/forward CMD+[] can be comfortably executed. There are no more inaccessible shortcuts such as Shift+CMD+? or changing playback speed on Youtube. Specials are somewhat annoying to type with `alt+u aou` and `alt + s`, but nothing I couldn't get used to.
- awelxtr 3y ago
  Spaniard here. I've done it all my life. Maybe my pain tolerance is way higher? Edit: I don't know what's wrong with pressing several keys at once to do something. It is like complaining that piano has no individual keys for all the possible chords. What's the alternative? Pressing a single key? What would you be doing with the rest of your fingers anyway?
  - marginalia_nu 3y ago
    The problem is that you need to press multiple keys with the same hand. Typically when touch-typing you press modifier keys with the other hand, to avoid having to move the hand in awkward ways, or typing with the left hand on the right side of the keyboard or some other weird solution. On top of that, alt+7 is spectacularly awkward, as you need to curl one finger really aggressively and extend another to reach both keys. Many of these keys are indeed accessible with a single keypress in US QWERTY. That, or a simple shift-combination. They're also much closer to the letter keys across the board.
  - AlbertoGP 3y ago
nntwozz 3y ago
I use a southpaw keyboard with arrow keys on the left side. I think it's a great design, it frees up space for the mouse bringing your arms closer together for a more ergonomic position. I'm not necessarily saying it's better but it makes you think about how input design shapes the use of software.

robenkleene 3y ago

I was once IDE-ish, and now Vim-ish, so I think I can answer this a bit. Everything you say is true (I guess except for the typing a lot, I don't find renaming a variable to feel like more typing in an IDE vs. Vim, but you're right that there are some IDE features that make some things easier). - The biggest problem I have with the IDE workflow is I was never able to get it to scale across projects effectively. E.g., lets say I want to make a find and replace for an API change across ten different projects, then run linters and compilation on all of them, and only be notified if there's an error, and otherwise make identical commits to all of the projects? - Another issue, is how easy is it for me to take the problem I'm working on, extract it to a complete different context, and then more quickly iterate on finding a solution? E.g., it's common for me to take what I'm working on, in say JavaScript, that's part of a larger application, and then copy/paste the entire problem into a single file with a `#!/usr/bin/env node` shebang, and then do a 1. edit/save 2. run `./my_script.js` workflow until I find the solution. With IDE's, I've found they often don't like working with single files that aren't part of a particular project. - When tracking down extremely difficult to find bugs, e.g., lets say you have several log files, thousands of lines long, and you want to use CLI tools to do custom analysis looking for patterns (e.g., is there a mismatch in order certain events firing in log files where the bug occurs vs. doesn't?). IDEs don't help much with this. There's a pattern with the above examples that's the main problem I had with IDEs is that they aren't flexible enough to scale to atypical workflows/problems. All of the above examples also leverage the command line, which is clearly a pattern. The CLI is just a useful open-ended tool to help programmatically solve any problem you might be facing. IDEs are great if you're adding a feature to an application, but they're less great if you're looking to adapt your tools to a specialized workflow that's a better fit for the problem at hand. Besides the above examples, I've also encountered code bases too large for JetBrains IDEs (rare, but they're out there), and generally find how slow they are to open windows to be disruptive to achieving flow state (I don't think this is normal, I think I personally experience latency more strongly than most other computer users, but just providing a complete picture). I also don't really find autocomplete very useful, which again is atypical, I use it in CLI-based editors like Vim/Emacs because it's trivial to add it with LSP support today, but would be fine working without it. Again it's about what you value, what I value is being able to adapt my tools to developing a specialized workflow to solve the problem at hand, over the features that IDEs offer.

laserlight 3y ago

> if typing speed ever becomes a bottleneck, something has gone horribly wrong somewhere. I've never understood such reasoning. Typing speed is a bottleneck. It cannot be parallelized with other tasks, and therefore, is on the critical path. Improving typing speed will shorten task duration. What is perhaps meant instead is that typing is not worth improving, because gains wouldn't affect overall task duration significantly. But then, why focus on percentage improvement over task duration? I use a keyboard all day. Any improvement affects my day-to-day quality of life for the rest of my life. Keypresses saved, finger, wrist, arm movements eliminated increases my comfort. Removing frictions in work increases flow.

thom 3y ago

I personally like not having to move around too much, but beyond CapsLock for Ctrl I’ve never stuck with anything fancy. That said, I don’t understand how typing speed doesn’t matter - I agree that’s mostly the case for code, but everything in between, from documentation to Slack chats, I think faster than I type and I’m always open to performance improvements. It’s also great if you can context switch with as little friction as possible so that you can hit the ground running each time. Overall it’s just about actions per second, not actual typing. I agree that IDEs and advanced editors help cut out a lot of stuff (I’ve never understood multiple cursors, for example, because as you say, that’s usually just a structured refactoring). But there are always opportunities to cut down cognitive load or speed up regular tasks. Whether hardware or software, we’re in tech because we believe better tools solve problems better.

ughitsaaron 3y ago

For me, not taking my hands off the keyboard (or more specifically, not touching the mouse) is less about speed, and more that it helps me remain focused on what I’m doing.

gumby 3y ago

> if typing speed ever becomes a bottleneck... The issue isn't really speed, it's moving your hands away from the core of the keyboard. Touch typing means you don't have to think about getting text into your machine (or modifying it) -- it just happens. Having to move your hand away to somewhere else (arrow keys or, shudder a mouse/trackpad) causes a microinterruption in your flow.

graypegg 3y ago

So, I use the Vim layer in IntelliJ. While it’s true that the IDE is doing a little bit of the repetitive typing work, there’s still things that are more comfortable with vim commands. To give an example you mentioned: > Why are you doing all this typing? If you update a variable name or a method signature and the rest of the code doesn't automatically update itself as far as possible, why is this? I use refactoring tools a ton! Rename Symbol works great. I’ll press the IDE combo for Refactor this (C-t) then the vim combo to, for example, add a suffix to the name that’s now highlighted by the IDE (wi SuffixNameHere<CR>) It’s not like it’s hard to do that by clicking the end of the word with the cursor, or moving to it with the arrow keys. But it’s so much more comfy to me, once you have a few movements in your head you can precisely communicate “go THERE” to your editor which is worth it to me. Bonus: @ macros! It’s so useful, even in IDEs, to be able to record (qx) and run (@x) a macro from your keyboard, while typing, if you notice that you’re repeating the same task. An IDE will help with renaming, removing, or re-signaturing… but not with the most annoying work, like numbering things or repeating blocks.