4 ms·

If your editor makes you significantly more productive, maybe you're just writing boilerplate code, or something someone already implemented in a library. Touch

by grecht 6y ago

If your editor makes you significantly more productive, maybe you're just writing boilerplate code, or something someone already implemented in a library. Touch typing is similar - it's useful because it removes some unnecessary barriers and thus makes the job more enjoyable, but it won't magically make you a better a programmer.

brobdingnagians 6y ago
I agree, but I think it is also like learning Lisp. I don't program in Lisp, but I think differently about some things because of it. Like code as a list that can be manipulated. Code as data, which is similar to Vim. Vim encourages thinking about things in terms of a language that represents structural units. I think more about how to code is structured rather than thinking about it as just freeform text with semantic meaning. Whether that structural mindset helps with programming.... Dunno.
cma 6y ago
Lots of times you could write something more succinctly with less boilerplate using, say, C preprocessor macros, but then end up losing out on debuggability, and sometimes searchability. Complex block based editing etc. is useful in those situations. It's a limitation of the tools.
0x008 6y ago
Yeah I always wonder who these people are for which the editor is a bottleneck and how they work or what they work on. 90% of my time is spent debugging, understanding legacy code and drawing trees or writing pseudo code on my notepad. The actual time I type stuff into an editor is like 10minutes per day.
- enriquto 6y ago
  Just a single data point, but as a matter of principle I never use a debugger. Any time spend inside the debugger is 100% lost and useless to other people. To study a code, it is best to copy it, run it, and keep adding assertions, comments, and logging infrastructure. Besides helping you to understand what the code does, all these changes are useful for other people who may need to understand the code in the future.
  - barbs 6y ago
    I don't understand - how is using a debugger a waste of time? I don't often use a debugger, but they have proven to be useful in a lot of cases.
    - DavidWoof 6y ago
      Not OP, and I think never using a debugger is silly, but IMO if I need a debugger to figure out a problem then I'm missing either sufficient unit tests or sufficient logging, and spending my time on that rather than in the debugger will aid future devs as well. I do think the write/debug/edit cycle is a very, very slow way to program, and I have to admit I'm suspicious when somebody tells me they spend 90% their time in the debugger (but a lot of this is dependent on type of work).
      - 0x008 6y ago
        I work with big data and have to solve a lot of problems in integration or by debugging again at the a live Systeme, which you simply cannot reproduce in local unit tests. And sometimes running a single test takes like 7 minutes so I have to reduce the times I run it to save time which is why I tend to fix code in an interactive REPL in the debugger.
    - enriquto 6y ago
      > I don't understand - how is using a debugger a waste of time? The debugger may help you understand, at some moment in time, what an unclear piece of code does. When you revisit this piece of code later, or another person finds it, your first experience with the debugger is not remembered, thus lost. This is what I meant. On the contrary, if you clarify the code and make it easier to instrumentate (by adding assertions, tests, comments, logging, etc.), it helps you right now, you in the future, and everybody else at any time. Furthermore, as a result of these efforts you will create a code that is clearer and nobody will ever need to debug to understand what it does. The only case where debugging makes sense to me is for cases that are difficult to add instrumentation to, like assembly programming, where it will be somewhat inevitable that you need to step through the instructions to see what's going on.
- roveo 6y ago
  It's not about typing speed, it's about reducing mental load. When vim (or any editor for that matter) becomes second nature, you stop thinking about how you're editing the text, it just happens, like moving a part of you body. And then you can better concentrate on the problem at hand, which matters even more for solving novel problems/algos/architecture. Same with touch typing: you don't need the speed, you need to eliminate the distraction of looking for a key. Even when you're debugging/reading code, you're still making small changes: adding a print here, removing an argument there. I read somewhere that the main insight behind creating vim was that you spend more time moving your cursor and parts of code around than you spend writing new code. So that's what it optimises for.
  - 0x008 6y ago
    Well I guess then it is different for each person what induces mental load. I for one sometimes just use my mouse to click and copy things or insert a character here and there or to go to some other line. Why? Because I can think about the next problem while I do that because I don’t have to think about any keystrokes.
horsawlarway 6y ago
I agree with this. This whole story gives me "hacker in movies" vibes. Programming isn't about artfully manipulating input devices while watching characters scroll fancifully across the screen. It's about understanding a problem in depth, and considering possible implementations/problems/edge cases. If you spend more time typing than thinking - I will unequivocally call you a bad developer (or a developer who's job is ripe for automation...). --- Now - no knock on Vim. I much prefer it to nano, and if you enjoy using it, more power to ya. I do agree there's a certain sense of "playing a musical instrument" feeling to it. But playing music and composing music are NOT the same. In the same way that entering text and programming are NOT the same.
- IggleSniggle 6y ago
  Before becoming a coder, I was a professional musician and composer. I think you are completely correct on all counts, but I think the spirit of your post misses one important facet. I compose because improvising on a single instrument is not enough for me. But it really is like improvising with edits, and being a good improviser will improve your compositions just as your compositions will improve your improvisations. And ultimately, you are doing these things because you love to play and hear music. The appeal of vim is that it encapsulates programmatic thinking into the act of editing. With each edit, you are making a little program: "select these words with these conditions but not those other conditions, and then, for the first (expression x/y) of them, transform them thusly. Then, select the parent containers, and pipe each one to this file-descriptor to be processed externally." But you can do this with a few keystrokes, you just have to think ahead a little. That is, it makes the act of programming and entering/editing text one and the same activity, allowing you to do little programmatic improvisations. I switched from music to code when I realized I got more enjoyment out of code than music. That is, I echo your statements "if you enjoy using it, more power to ya" and "playing music and composing are NOT the same," but also: sometimes playing music and composing are the same, and sometimes the only reason you are composing (or playing music) at all is because it feels so wonderful to do both at the same time.
chongli 6y ago
The magic of vim is not really showcased when starting up a new, blank file in a new project. If that's all programmers did, we wouldn't need an editor at all: just cat > foo.c and start typing! Where vim shines is with editing existing files. Sure, maybe your IDE has a great plugin (or great built-in support) for the specific language you're using in the project. But vim is excellent for editing any text file, no matter what language (or indeed no language at all), and its keys are always the same. If you become a vim master, you don't need language-specific support to be productive. Additionally, all of your knowledge of vim editing commands is transferrable to any kind of file you want to edit. Language-specific plugins, on the other hand, vary widely in capability, hotkey setup, and completeness. So if all you do all day is work exclusively within a single language and you have your IDE perfectly set up for it, learning vim is going to feel like a waste of time. If, on the other hand, you find yourself extremely unproductive whenever you move to edit other kinds of files (and you need to do this a lot), then vim may be a worthwhile investment of your time.

by grecht 6y ago

brobdingnagians 6y ago

I agree, but I think it is also like learning Lisp. I don't program in Lisp, but I think differently about some things because of it. Like code as a list that can be manipulated. Code as data, which is similar to Vim. Vim encourages thinking about things in terms of a language that represents structural units. I think more about how to code is structured rather than thinking about it as just freeform text with semantic meaning. Whether that structural mindset helps with programming.... Dunno.

cma 6y ago

Lots of times you could write something more succinctly with less boilerplate using, say, C preprocessor macros, but then end up losing out on debuggability, and sometimes searchability. Complex block based editing etc. is useful in those situations. It's a limitation of the tools.

0x008 6y ago

Yeah I always wonder who these people are for which the editor is a bottleneck and how they work or what they work on. 90% of my time is spent debugging, understanding legacy code and drawing trees or writing pseudo code on my notepad. The actual time I type stuff into an editor is like 10minutes per day.

enriquto 6y ago
Just a single data point, but as a matter of principle I never use a debugger. Any time spend inside the debugger is 100% lost and useless to other people. To study a code, it is best to copy it, run it, and keep adding assertions, comments, and logging infrastructure. Besides helping you to understand what the code does, all these changes are useful for other people who may need to understand the code in the future.
- barbs 6y ago
  I don't understand - how is using a debugger a waste of time? I don't often use a debugger, but they have proven to be useful in a lot of cases.
  - DavidWoof 6y ago
    Not OP, and I think never using a debugger is silly, but IMO if I need a debugger to figure out a problem then I'm missing either sufficient unit tests or sufficient logging, and spending my time on that rather than in the debugger will aid future devs as well. I do think the write/debug/edit cycle is a very, very slow way to program, and I have to admit I'm suspicious when somebody tells me they spend 90% their time in the debugger (but a lot of this is dependent on type of work).
    - 0x008 6y ago
      I work with big data and have to solve a lot of problems in integration or by debugging again at the a live Systeme, which you simply cannot reproduce in local unit tests. And sometimes running a single test takes like 7 minutes so I have to reduce the times I run it to save time which is why I tend to fix code in an interactive REPL in the debugger.
  - enriquto 6y ago
    > I don't understand - how is using a debugger a waste of time? The debugger may help you understand, at some moment in time, what an unclear piece of code does. When you revisit this piece of code later, or another person finds it, your first experience with the debugger is not remembered, thus lost. This is what I meant. On the contrary, if you clarify the code and make it easier to instrumentate (by adding assertions, tests, comments, logging, etc.), it helps you right now, you in the future, and everybody else at any time. Furthermore, as a result of these efforts you will create a code that is clearer and nobody will ever need to debug to understand what it does. The only case where debugging makes sense to me is for cases that are difficult to add instrumentation to, like assembly programming, where it will be somewhat inevitable that you need to step through the instructions to see what's going on.
roveo 6y ago
It's not about typing speed, it's about reducing mental load. When vim (or any editor for that matter) becomes second nature, you stop thinking about how you're editing the text, it just happens, like moving a part of you body. And then you can better concentrate on the problem at hand, which matters even more for solving novel problems/algos/architecture. Same with touch typing: you don't need the speed, you need to eliminate the distraction of looking for a key. Even when you're debugging/reading code, you're still making small changes: adding a print here, removing an argument there. I read somewhere that the main insight behind creating vim was that you spend more time moving your cursor and parts of code around than you spend writing new code. So that's what it optimises for.
- 0x008 6y ago
  Well I guess then it is different for each person what induces mental load. I for one sometimes just use my mouse to click and copy things or insert a character here and there or to go to some other line. Why? Because I can think about the next problem while I do that because I don’t have to think about any keystrokes.

horsawlarway 6y ago

I agree with this. This whole story gives me "hacker in movies" vibes. Programming isn't about artfully manipulating input devices while watching characters scroll fancifully across the screen. It's about understanding a problem in depth, and considering possible implementations/problems/edge cases. If you spend more time typing than thinking - I will unequivocally call you a bad developer (or a developer who's job is ripe for automation...). --- Now - no knock on Vim. I much prefer it to nano, and if you enjoy using it, more power to ya. I do agree there's a certain sense of "playing a musical instrument" feeling to it. But playing music and composing music are NOT the same. In the same way that entering text and programming are NOT the same.

IggleSniggle 6y ago
Before becoming a coder, I was a professional musician and composer. I think you are completely correct on all counts, but I think the spirit of your post misses one important facet. I compose because improvising on a single instrument is not enough for me. But it really is like improvising with edits, and being a good improviser will improve your compositions just as your compositions will improve your improvisations. And ultimately, you are doing these things because you love to play and hear music. The appeal of vim is that it encapsulates programmatic thinking into the act of editing. With each edit, you are making a little program: "select these words with these conditions but not those other conditions, and then, for the first (expression x/y) of them, transform them thusly. Then, select the parent containers, and pipe each one to this file-descriptor to be processed externally." But you can do this with a few keystrokes, you just have to think ahead a little. That is, it makes the act of programming and entering/editing text one and the same activity, allowing you to do little programmatic improvisations. I switched from music to code when I realized I got more enjoyment out of code than music. That is, I echo your statements "if you enjoy using it, more power to ya" and "playing music and composing are NOT the same," but also: sometimes playing music and composing are the same, and sometimes the only reason you are composing (or playing music) at all is because it feels so wonderful to do both at the same time.

chongli 6y ago

The magic of vim is not really showcased when starting up a new, blank file in a new project. If that's all programmers did, we wouldn't need an editor at all: just cat > foo.c and start typing! Where vim shines is with editing existing files. Sure, maybe your IDE has a great plugin (or great built-in support) for the specific language you're using in the project. But vim is excellent for editing any text file, no matter what language (or indeed no language at all), and its keys are always the same. If you become a vim master, you don't need language-specific support to be productive. Additionally, all of your knowledge of vim editing commands is transferrable to any kind of file you want to edit. Language-specific plugins, on the other hand, vary widely in capability, hotkey setup, and completeness. So if all you do all day is work exclusively within a single language and you have your IDE perfectly set up for it, learning vim is going to feel like a waste of time. If, on the other hand, you find yourself extremely unproductive whenever you move to edit other kinds of files (and you need to do this a lot), then vim may be a worthwhile investment of your time.