5 ms·

The one thing I disagree is the thing about editors. When I began coding I spent hours tweaking my vimrc file and learning all the essentially random shortcuts

The one thing I disagree is the thing about editors. When I began coding I spent hours tweaking my vimrc file and learning all the essentially random shortcuts, and dealing with the absurdities of vimscript. (and debugging vim plugins that broke each other.) It felt like actual work while I was producing nothing. Now I just open vscode with default settings and I am productive right away. Who cares about editors, vscode is good enough. But maybe just vim sucks and I should have been playing with emacs all along, I don't know.

ivanjermakov 2y ago
> Now I just open vscode with default settings and I am productive right away. Is always so painful to watch how slow average developers are with the tool they use the most. Using mouse/touchpad to scroll/select word is unbelievably slow. Learning and configuring text editor that is customizable enough to not get in a way pays dividends really well. Programming is mostly reading and navigating through the code with "go to definition" and similar code actions. Just being able to do this really fast would give a huge productivity boost right away.
fragmede 2y ago
When you began coding, was there vscode? These days there's lazyvim to let you skip all that fine tuning if you want to "just use vim".
bregma 2y ago
I just open vi with default settings and am productive right away. I tried VS Code and couldn't get a "hello world" example to run out of the box after a half hour of trying. Who cares about other editors, vi is good enough.
- trustno2 2y ago
  And it's fine. Do what works for you. I just don't think playing with editor endlessly is a well spent time. It makes you feel like you do actual work when you don't. In my opinion.
  - lemonwaterlime 2y ago
    You only play with the editor endlessly if you’re the type of person to play with the editor endlessly. My vimrc was set up over the years a bit at a time based on my needs. After several years, I did an overhaul based on what I truly need and don’t need from experience. I rarely change anything in it these days. Maybe a few lines if I start using a new language. With that stated, most of my vim use is still understanding buffers and motions, which takes no configuration.
  - naught0 2y ago
    These days you can write your neovim config in a real language -- lua. I used a pre-defined config called Lazy that does everything vscode can. Then I started tweaking shortcuts, removing and adding plugins, learning more lua. Then, after I knew what I wanted, I wrote my config from scratch with only the plugins and settings and keybinds I wanted. It was a very fun process for me. I enjoy simply using my editor. It makes me want to code. I don't get that same level of joy or customization from vscode -- which is phenomenal software btw. e: replied to the wrong comment in the chain, but the point stands! Customization is how I got into programming. Crafting a status bar on linux, tweaking colorschemes, etc. Don't hate on the tinkerers just because it's not how you enjoy to work. It can be immensely valuable
- g15jv2dp 2y ago
  > I just open vi with default settings and am productive right away. I tried VS Code and couldn't get a "hello world" example to run out of the box after a half hour of trying. I take it that you've learned vim (otherwise you wouldn't be "productive right away" - you wouldn't even know how to input text or save a file) whereas you had apparently never tried vscode before. How can that be a fair comparison?
- TillE 2y ago
  The VS Code launch settings crap is a mess. But like as an editor, it's an editor. You can just use it like that. It works well and has good defaults, you can open a terminal with a hotkey, etc.
bobajeff 2y ago
Same here. I don't spend most of my time typing but rather thinking. So getting good at vim or getting faster at typing will not make me any better. That's not to say that I'm not in favor of being good at typing. I know my keyboard well enough to touch type also I know some keyboard short cuts specific to vscode but they are intuitive and have a GUI alternative if I don't feel like using them.
- trustno2 2y ago
  One of my colleagues was using dvorak and arguing that because he types faster with it, he's a better programmer. i never thought typing speed is all that important when you code. But he DID write crazy fast.
  - j45 2y ago
    Typing fast is an interesting metric. Shipping the same code will happen sooner if you have tooling and typing setup to allow for quick iterations, and being quick in making those iterations. Selecting a language/framework that might take more work can slow you down too. Typing faster does seem to look towards thinking faster, trouble shooting faster. One place where it can get someone into trouble is typing too fast, faster than it might take to think through and not over look something which might invalidate what you're doing. I have all hires do typeracer.com. Not for a high or a low score, but seeing the development of the score and understanding the importance of typing fast relating to thinking fast. Typing code inherently is slower than writing sentences, so if you can type faster sentences in written communication, typing code will be faster, even if it's not at the full typing speed.
- tdumitrescu 2y ago
  I think everyone's got a different threshold for where returns start diminishing sharply. While I'm squarely in the "don't waste time micro-tweaking your editor" camp, there are some little bits of shortcuts and tooling that made me much more fluent at code-editing with very little investment. One example that stands out is the multi-cursor support that Sublime Text popularized (and which I use all the time in vscode now). It eliminates a good 80% of repetitive typing, or symbol refactoring that would have involved clunking through menus in old IDEs, and makes experimentation that much quicker. Feels fundamental, like copy/paste shortcuts which everyone knows now.
posix86 2y ago
VSCode can also be used more or less effectively though. There are quite a few shortcuts & tricks that can make you 10x more productive, even if maybe it's not as much as vim.
- sethammons 2y ago
  Multi-cursor on ten lines, sure. You get 10x for some seconds or maybe minutes. I'd expect practically zero people have gotten 3x more productive over a two week period for having advanced knowledge of tips and tricks in their editor. Saying 10x seems a wild exaggeration
goosejuice 2y ago
I'm grateful that I started learning vim and C at the same time in undergrad. Sure vscode is good enough, but a lot of value is gained tweaking your own tools beyond the tool itself. Producing something doesn't always need to be the goal. Exploration has value.
DavidWoof 2y ago
I don't think this point is about configuring your editor/environment as much as just knowing it. There's certain features that come up all the time: find file, find class, go to implementation, find references, rename var, etc. It stuns me how many devs do this stuff manually, when virtually all editors/ides have ways of doing these things.
- darby_nine 2y ago
  In some ecosystems, the tooling is just not that good. To use ruby on rails as an example: if you lean into the IDE's expectations for code layout it works ok, but there will always be generated methods and variables with nothing to show but the name—no documentation, no source, no googleable identifier, nothing. In these cases there's nothing to do but pull out the rails (or library) source to try and discern their intention. In my experience, lisp also has this issue of being very difficult to tool in a general sense, as did aspects of writing c/c++ years ago (maybe recognizing stuff like macro-generated symbols has improved by now).
  - skydhash 2y ago
    > lisp also has this issue of being very difficult to tool in a general sense Most of the common lisp tooling is already present in the language itself. Things like inspect, trace, describe and apropos already gives you the equivalent of most IDEs. I agree with you for some dynamic language and magic methods. It can be hard to trace back the exact function that are being called. But you can always design some tooling for it as long as the code follows the ecosystem convention (Laravel plugin in PhpStorm). The nice thing about Vim (and other configurable editors) is how easy to mesh existing tooling with the editor itself, without requiring for that extension to be a whole project unto itself.
  - Chris_Newton 2y ago
    This is a disadvantage of the more dynamic languages, I find. IDEs for languages like C++ and Java are relatively fast and accurate when jumping to definitions, showing references, performing automated refactorings and so on. I rarely see that same precision for any editor or IDE working with TypeScript, Python, and other very dynamic languages, even with the improvements recently thanks to LSP and generally better tools. When almost anything could theoretically have been patched at runtime — even if doing so would be a terrible idea and every style guide says don’t do it — it’s not safe for tools to make the same kind of assumptions with the more dynamic languages that they can with the more static ones.
corytheboyd 2y ago
100% agree about defaults. I do think it’s critical you actually learn the features of you IDE. Yes being able to type fast has nothing to with programming, but being able to jump to symbols, make refactors, use keyboard shortcuts etc. reduces the gap between hands and brain.
Chris_Newton 2y ago
Possibly my all-time favourite XKCD, Is it worth the time?¹, demonstrates two important points. If you only do something very rarely anyway, spending time to automate it won’t have a great ROI. But for things you do moderately often that take a minute or even just a few seconds, you can afford to spend a surprisingly large amount of time optimising them and still get a big pay-off over a time frame measured in years. I view time spent learning to use my tools efficiently and automating common tasks as a sound investment. Editors are a great example. Sure, I could fire up any of the usual suspects and write code somewhat productively. But in my fully customised editor of choice, I can insert and adapt common code patterns that would take me 10–30 seconds to type out fully in mere moments using templates and macros. I can jump to any position visible on-screen with around three keystrokes. I can see syntax highlighting for various file types that I use all the time, including some unusual ones that don’t have definitions readily available, and warnings for several different programming languages in real time as I work. These save me a few seconds every time I use them, but how many times is that every day? The effort to set them up has probably repaid itself 100x over by now! And the lack of latency is also a qualitative improvement since it means once I’m ready to start writing, I can do so roughly as fast as I can think, instead of constantly being held back and interrupted for a moment. ¹ https://xkcd.com/1205/ https://xkcd.com/1205/
- tdumitrescu 2y ago
  > If you only do something very rarely anyway, spending time to automate it won’t have a great ROI For code-editing, maybe. But in general software engineering, there are tasks that I have to do maybe once a year or less that are always way more painful than they need to be because I don't remember the details, and anytime I automate even part of them (or yes, just document a little better), it turns out to be well worth it. Stuff like bootstrapping new environments, some database-related work, etc.
  - cratermoon 2y ago
    Do hard things more often. https://martinfowler.com/bliki/FrequencyReducesDifficulty.html https://martinfowler.com/bliki/FrequencyReducesDifficulty.ht...
farmeroy 2y ago
I've been using neovim pretty much since I began programming. I had some initial setup and have tweaked it once or twice, but it's by no means been a source of sunk time for me. I recently had to switch to VSCode and had a lot of issues learning all the out of the box key bindings and not having the telescope and fuzzy find windows I was used to was a huge productivity loss for me. When I able to jump back to neovim it was such a huge relief.
- j45 2y ago
  I'm reasonably familiar with both and use them for different cases than each other. vscode at least is my text editor in the gui... but consistently growing :) The time getting up to speed on something new shouldn't be used against something else that is already familiar. Now if the new tool (ie., vscode) could import your neovim setup and get you an equivalent, that would be neat. Comparing the sunk cost time for neovim vs vscode might be a more interesting comparison. Neovim definitely is a little more polished than vim out of the box so it's entirely plausible it's pretty close. If a vim user wanted to learn something like vscode, they could just install a vim extension in vscode to navigate most of vscode in vim keys. Lots on youtube. It's hard to use a web browser without a vim extension installed. It's true if you have sunk the time to super customize a setup for you in anything (currently I'm working through my Aerospace setup), the part that I get caught by sometimes is that something I had to customize in neovim, might already be built into vscode, or something else, or vice versa. Repetitions is about creating the muscle memory, similar to building the same keys with vim. I'm lucky I was able to get to a place of comfort with vim when I had lots of free time. It's great when I don't have my setup with me, but my setup with neovim was a step forward, but vscode still sometimes just ends up where I am, and I figure out how to get it behaving a little better.
  - farmeroy 2y ago
    I guess my point was that, often times people say some tool (or language, or anything) is easier when what they really mean is that they are used to it. The fact is, you use something because it resonates with you (or its the only resource you have) and then you get good at it, and then everything else becomes a handicap
hinkley 2y ago
I’m on the fence. When I obsessed more about Flow State, I really did see dividends from spending spare cycles reading the docs (especially release notes) and keyboard shortcut mappings to find faster ways to do things I did often. Maybe I hit the point of diminishing returns. Maybe it’s because I don’t Code Like Hell much anymore, but it’s a habit I got out of. I keep resolving to getting back to it, but the fact I don’t maybe telling me something. Like maybe I’ve filled that spare time with other things that are more valuable.
__turbobrew__ 2y ago
My productivity is rarely limited by the speed with which I can interface with a computer. Im in the same boat, I just use intellij for everything.
seabass-labrax 2y ago
The author claims that a strong knowledge of development tools is a good indicator of general proficiency, but what if it's that learning how to use your editor makes you proficient? After all, nobody gets familiar with Emacs without inadvertently becoming a practitioner - if not an enthusiast - of Lisp! That happened with me, and I'm now a big fan of functional programming, Clojure, Scheme etc., and that experience and exposure to a particular way of writing code has undoubtedly made me a better programmer. It sounds like you've had a similar experience with Vimscript :)
- trustno2 2y ago
  I hate vimscript. vimscript is a horrible language.
- kazinator 2y ago
  > nobody gets familiar with Emacs without inadvertently becoming a practitioner - if not an enthusiast - of Lisp So you might think, until you meet a fervent Emacs advocate that doesn't know anything about "the underlying Lisp stuff".
coffeebeqn 2y ago
It’s a little bit like some productivity blogs obsessing over the notepad and pens and apps they use and spending a lot of time obsessing/procrastinating over things that don’t matter. I still learn the same shortcuts I’ve used for the last 15 years in whatever editor I use but most of my time is spent thinking and talking about problems rather than just typing things in the editor
moonshinefe 2y ago
As with most things there's a balance. I've found if I try to learn one or two new features or shortcuts every couple weeks with the tools I use extensively, eventually I do get a sharp axe. Typing speed is nice but not an important metric I don't think. It's like someone speeding past you on the road only for you to see them at the next red light. Other things will slow you down like code review or needing to wait until a set time to deploy. Also things like copilot and advanced auto-completion are making it less relevant.
wruza 2y ago
Now I just open vscode with default settings and I am productive right away. I am right away distracted by a huge rectangle around cursor line, current word highlighting and general jumpiness of everything. Coding in vscode feels like writing a book in the middle of brazilian festival. And then it cannot do random simple things like proper indents or humane snippets. The amount of work required to unfuck vscode is really comparable to creating .vimrc from scratch.
- james_marks 2y ago
  Same. I don't know why exactly, but VSCode feels like I'm programming inside an advertisement, and makes my skin crawl.
- gverrilla 2y ago
  I'm a novice. I have only used vscode and sublime. Both have a problem when copying code from elsewhere, where the indent will be wrong every time somehow. If that's what you're talking about, is there an editor that will figure it out correctly somehow? Thanks
  - Chris_Newton 2y ago
    In Sublime, there is a command to paste while matching the indentation as well. I think it’s Ctrl+Shift+V on most platforms by default. Maybe that’s what you’re looking for?
  - wruza 2y ago
    I was talking about nested indents, like this: f(a, b, g(c, d ) ) Vscode cannot indent it properly due to how indent rules (simple regexes) work. Formatters like “prettier” exist but they can only format whole-file. Maybe try that (downside being you’re at its mercy completely). I guess you are experiencing either auto-indent like that or the partially selected lines problem (when selection doesn’t touch \n at both ends). Vscode and sublime should also have a way to “paste raw” without reindenting. Try copying proper non-partial lines and/or pasting raw at column 0, removing automatic indent and adding yours afterwards. I know it’s tedious but I’ve seen enough people editing in ms-style editors and they all had this issue. Most just accept it as a fact of life. As a vim user I’m afraid I can’t help much here. My copy-pasting is almost always line-oriented (V-mode copied lines always pasted after current line, regardless where the cursor is) and indent rules are very robust so it rarely indents things wrong. I also have gv> and gv= to re/indent just pasted text. I’d ask on stackoverflow (stackexchange) or on HN which popular editors have whole-line modes or maybe vscode/sublime plugins which can help with that.
rldjbpin 2y ago
This. i am much junior but from my experience, working with the toolchain of your team is better in the long run than against it. if you become proficient quickly with whatever your team works with, it is much better overall than making everyone accommodate you. i have worked in teams where getting neovim installed would confuse the IT as they don't get those requests (or may not even know it exists!).
myaccountonhn 2y ago
Learning vim teaches you new ways to think about code editing and is useful if you ssh into machines. I think learning in itself has value, and I think even if you go back to vscode it might have taught you how to better navigate, maybe you realized for example that file trees aren’t so efficient and it’s best to navigate via the fuzzy search. Then there is also the collective argument that letting Microsoft have editor monopoly can be really disastrous.
globular-toast 2y ago
> But maybe just vim sucks and I should have been playing with emacs all along, I don't know. Honestly, yes, I think this is it. Ok, vim doesn't suck as a text editor, but it sucks if what you really wanted was VS Code. Emacs, however, doesn't suck. I spend very little time tweaking my Emacs config these days, but when I do it's to fix things VS Code users just have to put up with. I've watched over their shoulders. They put up with a lot.
thom 2y ago
I'm always slightly sad when software developers are confident that software can't possibly make them more productive.

ivanjermakov 2y ago

> Now I just open vscode with default settings and I am productive right away. Is always so painful to watch how slow average developers are with the tool they use the most. Using mouse/touchpad to scroll/select word is unbelievably slow. Learning and configuring text editor that is customizable enough to not get in a way pays dividends really well. Programming is mostly reading and navigating through the code with "go to definition" and similar code actions. Just being able to do this really fast would give a huge productivity boost right away.

fragmede 2y ago

When you began coding, was there vscode? These days there's lazyvim to let you skip all that fine tuning if you want to "just use vim".

bregma 2y ago

I just open vi with default settings and am productive right away. I tried VS Code and couldn't get a "hello world" example to run out of the box after a half hour of trying. Who cares about other editors, vi is good enough.

trustno2 2y ago
And it's fine. Do what works for you. I just don't think playing with editor endlessly is a well spent time. It makes you feel like you do actual work when you don't. In my opinion.
- lemonwaterlime 2y ago
  You only play with the editor endlessly if you’re the type of person to play with the editor endlessly. My vimrc was set up over the years a bit at a time based on my needs. After several years, I did an overhaul based on what I truly need and don’t need from experience. I rarely change anything in it these days. Maybe a few lines if I start using a new language. With that stated, most of my vim use is still understanding buffers and motions, which takes no configuration.
- naught0 2y ago
  These days you can write your neovim config in a real language -- lua. I used a pre-defined config called Lazy that does everything vscode can. Then I started tweaking shortcuts, removing and adding plugins, learning more lua. Then, after I knew what I wanted, I wrote my config from scratch with only the plugins and settings and keybinds I wanted. It was a very fun process for me. I enjoy simply using my editor. It makes me want to code. I don't get that same level of joy or customization from vscode -- which is phenomenal software btw. e: replied to the wrong comment in the chain, but the point stands! Customization is how I got into programming. Crafting a status bar on linux, tweaking colorschemes, etc. Don't hate on the tinkerers just because it's not how you enjoy to work. It can be immensely valuable
g15jv2dp 2y ago
> I just open vi with default settings and am productive right away. I tried VS Code and couldn't get a "hello world" example to run out of the box after a half hour of trying. I take it that you've learned vim (otherwise you wouldn't be "productive right away" - you wouldn't even know how to input text or save a file) whereas you had apparently never tried vscode before. How can that be a fair comparison?
TillE 2y ago
The VS Code launch settings crap is a mess. But like as an editor, it's an editor. You can just use it like that. It works well and has good defaults, you can open a terminal with a hotkey, etc.

bobajeff 2y ago

Same here. I don't spend most of my time typing but rather thinking. So getting good at vim or getting faster at typing will not make me any better. That's not to say that I'm not in favor of being good at typing. I know my keyboard well enough to touch type also I know some keyboard short cuts specific to vscode but they are intuitive and have a GUI alternative if I don't feel like using them.

trustno2 2y ago
One of my colleagues was using dvorak and arguing that because he types faster with it, he's a better programmer. i never thought typing speed is all that important when you code. But he DID write crazy fast.
- j45 2y ago
  Typing fast is an interesting metric. Shipping the same code will happen sooner if you have tooling and typing setup to allow for quick iterations, and being quick in making those iterations. Selecting a language/framework that might take more work can slow you down too. Typing faster does seem to look towards thinking faster, trouble shooting faster. One place where it can get someone into trouble is typing too fast, faster than it might take to think through and not over look something which might invalidate what you're doing. I have all hires do typeracer.com. Not for a high or a low score, but seeing the development of the score and understanding the importance of typing fast relating to thinking fast. Typing code inherently is slower than writing sentences, so if you can type faster sentences in written communication, typing code will be faster, even if it's not at the full typing speed.
tdumitrescu 2y ago
I think everyone's got a different threshold for where returns start diminishing sharply. While I'm squarely in the "don't waste time micro-tweaking your editor" camp, there are some little bits of shortcuts and tooling that made me much more fluent at code-editing with very little investment. One example that stands out is the multi-cursor support that Sublime Text popularized (and which I use all the time in vscode now). It eliminates a good 80% of repetitive typing, or symbol refactoring that would have involved clunking through menus in old IDEs, and makes experimentation that much quicker. Feels fundamental, like copy/paste shortcuts which everyone knows now.

posix86 2y ago

VSCode can also be used more or less effectively though. There are quite a few shortcuts & tricks that can make you 10x more productive, even if maybe it's not as much as vim.

sethammons 2y ago
Multi-cursor on ten lines, sure. You get 10x for some seconds or maybe minutes. I'd expect practically zero people have gotten 3x more productive over a two week period for having advanced knowledge of tips and tricks in their editor. Saying 10x seems a wild exaggeration

goosejuice 2y ago

I'm grateful that I started learning vim and C at the same time in undergrad. Sure vscode is good enough, but a lot of value is gained tweaking your own tools beyond the tool itself. Producing something doesn't always need to be the goal. Exploration has value.

DavidWoof 2y ago

I don't think this point is about configuring your editor/environment as much as just knowing it. There's certain features that come up all the time: find file, find class, go to implementation, find references, rename var, etc. It stuns me how many devs do this stuff manually, when virtually all editors/ides have ways of doing these things.

darby_nine 2y ago
In some ecosystems, the tooling is just not that good. To use ruby on rails as an example: if you lean into the IDE's expectations for code layout it works ok, but there will always be generated methods and variables with nothing to show but the name—no documentation, no source, no googleable identifier, nothing. In these cases there's nothing to do but pull out the rails (or library) source to try and discern their intention. In my experience, lisp also has this issue of being very difficult to tool in a general sense, as did aspects of writing c/c++ years ago (maybe recognizing stuff like macro-generated symbols has improved by now).
- skydhash 2y ago
  > lisp also has this issue of being very difficult to tool in a general sense Most of the common lisp tooling is already present in the language itself. Things like inspect, trace, describe and apropos already gives you the equivalent of most IDEs. I agree with you for some dynamic language and magic methods. It can be hard to trace back the exact function that are being called. But you can always design some tooling for it as long as the code follows the ecosystem convention (Laravel plugin in PhpStorm). The nice thing about Vim (and other configurable editors) is how easy to mesh existing tooling with the editor itself, without requiring for that extension to be a whole project unto itself.
- Chris_Newton 2y ago
  This is a disadvantage of the more dynamic languages, I find. IDEs for languages like C++ and Java are relatively fast and accurate when jumping to definitions, showing references, performing automated refactorings and so on. I rarely see that same precision for any editor or IDE working with TypeScript, Python, and other very dynamic languages, even with the improvements recently thanks to LSP and generally better tools. When almost anything could theoretically have been patched at runtime — even if doing so would be a terrible idea and every style guide says don’t do it — it’s not safe for tools to make the same kind of assumptions with the more dynamic languages that they can with the more static ones.

corytheboyd 2y ago

100% agree about defaults. I do think it’s critical you actually learn the features of you IDE. Yes being able to type fast has nothing to with programming, but being able to jump to symbols, make refactors, use keyboard shortcuts etc. reduces the gap between hands and brain.

Chris_Newton 2y ago

Possibly my all-time favourite XKCD, Is it worth the time?¹, demonstrates two important points. If you only do something very rarely anyway, spending time to automate it won’t have a great ROI. But for things you do moderately often that take a minute or even just a few seconds, you can afford to spend a surprisingly large amount of time optimising them and still get a big pay-off over a time frame measured in years. I view time spent learning to use my tools efficiently and automating common tasks as a sound investment. Editors are a great example. Sure, I could fire up any of the usual suspects and write code somewhat productively. But in my fully customised editor of choice, I can insert and adapt common code patterns that would take me 10–30 seconds to type out fully in mere moments using templates and macros. I can jump to any position visible on-screen with around three keystrokes. I can see syntax highlighting for various file types that I use all the time, including some unusual ones that don’t have definitions readily available, and warnings for several different programming languages in real time as I work. These save me a few seconds every time I use them, but how many times is that every day? The effort to set them up has probably repaid itself 100x over by now! And the lack of latency is also a qualitative improvement since it means once I’m ready to start writing, I can do so roughly as fast as I can think, instead of constantly being held back and interrupted for a moment. ¹ https://xkcd.com/1205/ https://xkcd.com/1205/

tdumitrescu 2y ago
> If you only do something very rarely anyway, spending time to automate it won’t have a great ROI For code-editing, maybe. But in general software engineering, there are tasks that I have to do maybe once a year or less that are always way more painful than they need to be because I don't remember the details, and anytime I automate even part of them (or yes, just document a little better), it turns out to be well worth it. Stuff like bootstrapping new environments, some database-related work, etc.
- cratermoon 2y ago
  Do hard things more often. https://martinfowler.com/bliki/FrequencyReducesDifficulty.html https://martinfowler.com/bliki/FrequencyReducesDifficulty.ht...

farmeroy 2y ago

I've been using neovim pretty much since I began programming. I had some initial setup and have tweaked it once or twice, but it's by no means been a source of sunk time for me. I recently had to switch to VSCode and had a lot of issues learning all the out of the box key bindings and not having the telescope and fuzzy find windows I was used to was a huge productivity loss for me. When I able to jump back to neovim it was such a huge relief.

j45 2y ago
I'm reasonably familiar with both and use them for different cases than each other. vscode at least is my text editor in the gui... but consistently growing :) The time getting up to speed on something new shouldn't be used against something else that is already familiar. Now if the new tool (ie., vscode) could import your neovim setup and get you an equivalent, that would be neat. Comparing the sunk cost time for neovim vs vscode might be a more interesting comparison. Neovim definitely is a little more polished than vim out of the box so it's entirely plausible it's pretty close. If a vim user wanted to learn something like vscode, they could just install a vim extension in vscode to navigate most of vscode in vim keys. Lots on youtube. It's hard to use a web browser without a vim extension installed. It's true if you have sunk the time to super customize a setup for you in anything (currently I'm working through my Aerospace setup), the part that I get caught by sometimes is that something I had to customize in neovim, might already be built into vscode, or something else, or vice versa. Repetitions is about creating the muscle memory, similar to building the same keys with vim. I'm lucky I was able to get to a place of comfort with vim when I had lots of free time. It's great when I don't have my setup with me, but my setup with neovim was a step forward, but vscode still sometimes just ends up where I am, and I figure out how to get it behaving a little better.
- farmeroy 2y ago
  I guess my point was that, often times people say some tool (or language, or anything) is easier when what they really mean is that they are used to it. The fact is, you use something because it resonates with you (or its the only resource you have) and then you get good at it, and then everything else becomes a handicap

hinkley 2y ago

I’m on the fence. When I obsessed more about Flow State, I really did see dividends from spending spare cycles reading the docs (especially release notes) and keyboard shortcut mappings to find faster ways to do things I did often. Maybe I hit the point of diminishing returns. Maybe it’s because I don’t Code Like Hell much anymore, but it’s a habit I got out of. I keep resolving to getting back to it, but the fact I don’t maybe telling me something. Like maybe I’ve filled that spare time with other things that are more valuable.

__turbobrew__ 2y ago

My productivity is rarely limited by the speed with which I can interface with a computer. Im in the same boat, I just use intellij for everything.

seabass-labrax 2y ago

The author claims that a strong knowledge of development tools is a good indicator of general proficiency, but what if it's that learning how to use your editor makes you proficient? After all, nobody gets familiar with Emacs without inadvertently becoming a practitioner - if not an enthusiast - of Lisp! That happened with me, and I'm now a big fan of functional programming, Clojure, Scheme etc., and that experience and exposure to a particular way of writing code has undoubtedly made me a better programmer. It sounds like you've had a similar experience with Vimscript :)

trustno2 2y ago
I hate vimscript. vimscript is a horrible language.
kazinator 2y ago
> nobody gets familiar with Emacs without inadvertently becoming a practitioner - if not an enthusiast - of Lisp So you might think, until you meet a fervent Emacs advocate that doesn't know anything about "the underlying Lisp stuff".

coffeebeqn 2y ago

It’s a little bit like some productivity blogs obsessing over the notepad and pens and apps they use and spending a lot of time obsessing/procrastinating over things that don’t matter. I still learn the same shortcuts I’ve used for the last 15 years in whatever editor I use but most of my time is spent thinking and talking about problems rather than just typing things in the editor

moonshinefe 2y ago

As with most things there's a balance. I've found if I try to learn one or two new features or shortcuts every couple weeks with the tools I use extensively, eventually I do get a sharp axe. Typing speed is nice but not an important metric I don't think. It's like someone speeding past you on the road only for you to see them at the next red light. Other things will slow you down like code review or needing to wait until a set time to deploy. Also things like copilot and advanced auto-completion are making it less relevant.

wruza 2y ago

Now I just open vscode with default settings and I am productive right away. I am right away distracted by a huge rectangle around cursor line, current word highlighting and general jumpiness of everything. Coding in vscode feels like writing a book in the middle of brazilian festival. And then it cannot do random simple things like proper indents or humane snippets. The amount of work required to unfuck vscode is really comparable to creating .vimrc from scratch.

james_marks 2y ago
Same. I don't know why exactly, but VSCode feels like I'm programming inside an advertisement, and makes my skin crawl.
gverrilla 2y ago
I'm a novice. I have only used vscode and sublime. Both have a problem when copying code from elsewhere, where the indent will be wrong every time somehow. If that's what you're talking about, is there an editor that will figure it out correctly somehow? Thanks
- Chris_Newton 2y ago
  In Sublime, there is a command to paste while matching the indentation as well. I think it’s Ctrl+Shift+V on most platforms by default. Maybe that’s what you’re looking for?
- wruza 2y ago
  I was talking about nested indents, like this: f(a, b, g(c, d ) ) Vscode cannot indent it properly due to how indent rules (simple regexes) work. Formatters like “prettier” exist but they can only format whole-file. Maybe try that (downside being you’re at its mercy completely). I guess you are experiencing either auto-indent like that or the partially selected lines problem (when selection doesn’t touch \n at both ends). Vscode and sublime should also have a way to “paste raw” without reindenting. Try copying proper non-partial lines and/or pasting raw at column 0, removing automatic indent and adding yours afterwards. I know it’s tedious but I’ve seen enough people editing in ms-style editors and they all had this issue. Most just accept it as a fact of life. As a vim user I’m afraid I can’t help much here. My copy-pasting is almost always line-oriented (V-mode copied lines always pasted after current line, regardless where the cursor is) and indent rules are very robust so it rarely indents things wrong. I also have gv> and gv= to re/indent just pasted text. I’d ask on stackoverflow (stackexchange) or on HN which popular editors have whole-line modes or maybe vscode/sublime plugins which can help with that.

rldjbpin 2y ago

This. i am much junior but from my experience, working with the toolchain of your team is better in the long run than against it. if you become proficient quickly with whatever your team works with, it is much better overall than making everyone accommodate you. i have worked in teams where getting neovim installed would confuse the IT as they don't get those requests (or may not even know it exists!).

myaccountonhn 2y ago

Learning vim teaches you new ways to think about code editing and is useful if you ssh into machines. I think learning in itself has value, and I think even if you go back to vscode it might have taught you how to better navigate, maybe you realized for example that file trees aren’t so efficient and it’s best to navigate via the fuzzy search. Then there is also the collective argument that letting Microsoft have editor monopoly can be really disastrous.

globular-toast 2y ago

> But maybe just vim sucks and I should have been playing with emacs all along, I don't know. Honestly, yes, I think this is it. Ok, vim doesn't suck as a text editor, but it sucks if what you really wanted was VS Code. Emacs, however, doesn't suck. I spend very little time tweaking my Emacs config these days, but when I do it's to fix things VS Code users just have to put up with. I've watched over their shoulders. They put up with a lot.

thom 2y ago

I'm always slightly sad when software developers are confident that software can't possibly make them more productive.