7 ms·

> I was already a keyboard maximalist from previous jobs where I learned speed = productivity I've never understood this. In over 30 years in the industry, I'v

> I was already a keyboard maximalist from previous jobs where I learned speed = productivity I've never understood this. In over 30 years in the industry, I've not once held a job where my keyboard speed had a noticeable effect on my productivity. Even when I had to type one-handed for a month, my productivity was unchanged. The average developer averages 10 lines of finished code per day. And even with a raw 10x that amount to account for variance, changes, debugging etc, you'd be at 12 lines PER HOUR. Being generous at a full 80 chars per line, you have a maximum of 1000 keypresses per hour, or an average of one every 3 seconds. Even doubling your typing speed or keyboard response time would have no discernible effect. 90% of software development happens in the mind. The small amount of time spent actually writing it out seems kinda silly to optimize for.

meitham 2y ago
I don’t touch type and I’m fully with you on speed doesn’t increase performance, but I have recently started writing c# after two decades of python and man the number of lines that you have to write before you get to the meat of the logic! So I think that 10 lines of code are only to expressive languages not globally
- MrJohz 2y ago
  In fairness, I don't have so much experience with C#, but my experience with Java and OO-heavy JS codebases is that most of the boilerplate can be automated away without much problem - typing "cl<tab>" generates a class definition, and I can hit tab to jump between the different bits I need to fill in. With Copilot, this has become even easier because it is very good at guessing the relevant boilerplate to insert without needing to look through different options.
- owenpalmer 2y ago
  Learning to touch type is hard, but worth it. Once you learn, you'll realize the difference it makes.
  - arunix 2y ago
    It need not be hard. I learnt over the Christmas holidays using Kaz (https://kaz-type.com/ https://kaz-type.com/)
- neonsunset 2y ago
  Could you post an example of the boilerplate you are facing with? I’m sure it’s something that's perfectly avoidable.
mikojan 2y ago
It is important to be sufficiently fast at editing or else you will not revise what you wrote. I hear people complaining a lot: "This is tedious. That is tedious." They have no control over their development environments. They write code once and whatever was produced in the process will be checked-in as is. It is aggravating because there is this sentiment that it is fine to be incompetent. It is not.
lawn 2y ago
I think typing speed is important during bursts. If you can type out a function name really quickly (autocomplete also helps of course) then you can continue your thought process with less interruption than if you were slower. > 90% of software development happens in the mind. The small amount of time spent actually writing it out seems kinda silly to optimize for. So you're saying that 10% is spent typing, which doesn't seem a silly amount to optimize for?
- wokwokwok 2y ago
  Yes, quite so, but it probably has almost nothing to do with absolute typing speed. There’s a marginal difference between an editor where you can type quickly and one where you can only type fast. We’re not talking about the difference between 300 wpm and 10 wpm. I bet if you measured, you would see, at best, a marginal difference between the speed of input between editors. Ie. The point is that, that marginal difference probably has no meaningful difference in your productivity. What makes the difference is probably how it affects, for example; flow. If your flow is interrupted by the editor hanging or waiting for some bs lang server lag, or having to update a vim plugin, you are being interrupted. …and studies show that interruptions do have a meaningful impact on productivity. This is why editors that let you type fast do not improve productivity for everyone. Some people get flow in other ways. Fast typing is not a universal metric for productivity, and it’s absolutely a diminishing returns thing to optimise for. It’s probably fair to say that if you have a moderately fast editor, going to a super fast editor makes no difference to most people. …but going from an editor that freezes or forces you to spend your time upgrading plugins, probably does; because interruptions like that are probably universal flow destroyers.
Zambyte 2y ago
> 90% of software development happens in the mind. Why? The only reason I can think of for this to be true is when there is high risk in writing wrong code. For example, long compile times leading to a large sunken cost, or a lack of testing processes. Unless you're doing R&D, only spending 10% of your "coding" time actually writing code seems very low, and you should try to optimize the processes that are lacking.
- bvrmn 2y ago
  I personally have a pipeline of multiple tasks I'm thinking about in background. It easily could take a week to get details in my brain. During coding I get already worked out tasks. Most of the time it's a final design. My colleagues considers me as a 10x developer. 10% coding looks very real in my case.
- empthought 2y ago
  The highest risk in writing code is that the code written will have a negative value; i.e. it will incur more development cost over its lifetime than it will recoup via its intended effects. Hastily written, poorly justified or reasoned code has a much higher likelihood of having this flaw, so that’s why I would say you are wrong about this.
MaysonL 2y ago
I tend to keyboard minimalism myself: doing as little typing as is required to produce the code. I.e.: lots of keyboard macros. Thus reducing the cognitive load of typing to a minimum.
lelanthran 2y ago
> The average developer averages 10 lines of finished code per day. And even with a raw 10x that amount to account for variance, changes, debugging etc, you'd be at 12 lines PER HOUR. Being generous at a full 80 chars per line, you have a maximum of 1000 keypresses per hour, or an average of one every 3 seconds. Even doubling your typing speed or keyboard response time would have no discernible effect. Just my personal experience, it's not about how fast I can get my ideas down in writing (whether code or not), it's about how often I am broken out of the flow when typing. At one extreme, using your stats above of "10 finished lines of code per day", you could argue that using this keyboard (https://www.youtube.com/watch?v=9BnLbv6QYcA https://www.youtube.com/watch?v=9BnLbv6QYcA) should have no effect on your productivity, and yet no developer would make or support this argument. Small frictions add up; there's a joelonsoftware post that I read a long time ago about this[1], and it stuck for 24 years! The best editor/environment is the one that gets out of my way. One where I don't need to look things up on google. One in which I have already learned all the shortcuts, and don't need to relearn them to make the software useful. Emacs `M-x sql-connect` is much easier for me to do than to look up, in VS Code, what shortcut has been assigned to the extension I use that does the same thing, and then look it up again in a few years when that extension is no longer supported. Same for Vim commands. Using VS Code, or a full-fledged IDE[2] removes the whole command interface: I now need to remember dozens of key-chords, not a handful of verbs and a handful of nouns. I need to remember which menu, and which submenu needs to be clicked. Each time I want to do something in the IDE I switch focus from the code to the IDE. When in Vim or Emacs, that never happens! The "keyboard maximalism" isn't about speed == productivity, IME. It's about "friction == disruption". -------------------------------------------- [1] From https://www.joelonsoftware.com/2000/04/10/controlling-your-environment-makes-you-happy/ https://www.joelonsoftware.com/2000/04/10/controlling-your-e... > So that’s what days were like. A bunch of tiny frustrations, and a bunch of tiny successes. But they added up. Even something which seems like a tiny, inconsequential frustration affects your mood. Your emotions don’t seem to care about the magnitude of the event, only the quality. > And I started to learn that the days when I was happiest were the days with lots of small successes and few small frustrations. [2] Which I use daily, btw. I'm not knocking the developers who use IDEs.
- ReleaseCandidat 2y ago
owenpalmer 2y ago
> The average developer averages 10 lines of finished code per day This is a ridiculous statement. Citation needed.
- Asraelite 2y ago
  This is a relatively widely known claim, https://stackoverflow.com/questions/966800/mythical-man-month-10-lines-per-developer-day-how-close-on-large-projects https://stackoverflow.com/questions/966800/mythical-man-mont... It's debatable how accurate it is, but I think the ultimate productivity of developers is actually surprisingly lower than you would think.
- skitter 2y ago
  According to Stroustrup & co, it's less: They see a good dev optimistically writing 2k lines of finished non-test code a year, and that's when rewriting code ¹, so that checks out! (To be clear, I'm joking and agree with your sentiment, but they really did say that in an official reply to the US gov) ¹: https://downloads.regulations.gov/ONCD-2023-0002-0020/attachment_1.pdf https://downloads.regulations.gov/ONCD-2023-0002-0020/attach...
- Jare 2y ago
  Hopefully it's clear that: - code is not the only output produced by a developer. Communication, design, documentation, testing and tests, diagnosing and debugging, etc. - I can and do write hundreds of lines of working code in a given day (and I'm not an IC). But "finished" was meant to describe something that doesn't get touched again unless new work requires it. A lot of code today is written more iteratively, with mvps, experiments, baselining, refactoring, etc. An mvp is not (yet) finished. - 10 lines may be a low estimate today, but 100 is probably fair. (yeah varies a lot with language, boilerplate, etc) I hope the general agreement would be that the amount of characters of code written is definitely not the largest part of a developer's output, but reaching the point where a given line of code is "finished" involves a number of processes and lot of typing. And editors are an important part of many of those processes.
  - kstenerud 2y ago
kamaal 2y ago
>>I've not once held a job where my keyboard speed had a noticeable effect on my productivity. Features like vim/emacs macros do way than increasing the speed of accomplishing a task. They are a way of converting O(n^k) manual tasks to a O(1) task. These are ways of doing lots of work in fewer steps. This is if your work involves lots of text heavy lifting tasks. Speed many times is just a unintended but a welcome side effect. Real value is in not doing manual drudgery.
wtcactus 2y ago
I think this is a gross generalization. In my present work at DevOps, I could say it’s true IF we only look at code. When I was doing computational intensive simulations, I would write clearly 100 or more lines of code everyday.
hydroteur 2y ago
It depends on what you work with. If you debug a complex issue you need to check many different setups to see whether your suspicions are right. Then, having a nice workflow where you sticky edit and run your code is quite important. It's not always the case. Quite often the only way to investigate the issue is to run a cloud workload that takes several minutes to start. Still, if you write good code, you can try to isolate the issue for local debugging at some point.
svlasov 2y ago
If you know what you want to build, typing becomes a real bottleneck.
- vaylian 2y ago
  Plus, the more ground you can cover until someone interrupts you, the better.
kombine 2y ago
This is partly true, but there is a caveat: it's 10 lines of finished. In order to get there you would write and edit this piece of code many times over until it reaches the desired quality. And VIM is meant for "editing" code.
krig 2y ago
It’s not just about typing out code even though being able to do that quickly is more valuable than you realize. There are plenty of other areas where typing efficiently facilitates thinking about software. - Writing clear notes and design documents helps in developing ideas. - Writing documentation. - Writing commit messages and issue descriptions. - Writing emails and messages when communicating with others. Typing efficiently is only one factor here, communicating clearly and efficiently, reading comprehension… these are also important. But typing slowly impedes development of those related skills as well.
GuB-42 2y ago
It is true that most part of software development happens in the mind, but sometimes, the mind needs a support. Some use a pen and paper, some use specialized software, but for many, the text editor is that support. That's where they throw their ideas, sometimes in code, sometimes as a comment, or in a scrap file. Seen as a support it is important for the text editor to be as unobtrusive and responsive as possible, to not break the thread of thoughts. And slowness, even micro-stutters do that. Mastering the keyboard, which include knowing shortcuts, touch typing and generally typing fast also helps, so you think more about the problem and less about the keyboard when writing down your ideas. Now, if the way you code looks like you are meditating in front of the screen, not typing anything but the final solution, and I am sure some people do, then you probably don't need to work fast in the editor. To each his own, but personally, speed is an important factor in choosing a text editor. That's why I am currently on Sublime Text and not VS Code. Even though the latter is similar but free, more popular, and with interesting features, Sublime Text is faster, and I like speed. And may take a look at Zed, now that it is available on Linux.
dimal 2y ago
I agree that 90% of software development happens in the mind, but also that being a keyboard maximalist makes sense, at least for me. First of all, there’s the ease with which I can get those ideas out of my mind and into working code. If I’m fiddling with a mouse and dragging things around in some virtual 2D space, it adds cognitive load and puts my mind in the wrong mode for coding. When I’m editing in vim, it’s easy to get into flow. There’s also the case that when I’m planning my solution, I’m also using a text editor with vim bindings, so I can get into the same flow state more easily as I’m doing software design. And even though a coder might only produce an average of ten lines of code per day, that doesn’t mean I’m producing 10 lines each day. Some days I produce none, and other days I produce a hundred, so it makes sense to optimize for the days when I’m producing a hundred. Beyond that, even the idea of producing a line of code seems to assume that you’re only writing new code. I’d say that 70-80% of my coding is refactoring. I’m either refactoring existing code or refactoring the code I’m writing as I go. The ten lines I write in a given day may have been written as thirty lines in the first draft, then edited down. So, again, optimizing for flow here makes sense.
damnever 2y ago
I have to disagree; average is not a good way to measure. I have written approximately 6,000 lines of code (including empty lines but excluding some generated code) over the past few weeks. Yes, I write design documents before coding, and most of the code is completed within a few days. I definitely spend a lot of time debugging, but almost all of those activities have been constrained to code. Test cases are very helpful in making the process clean. I use Neovim inside iTerm2, so all those activities are done within terminal. By maximizing productivity through the use of the keyboard, I can eliminate many dependencies, such as the mouse and multiple displays. I believe dependencies are a source of distractions. Most importantly, writing helps thinking. When I am stuck, I just write random comments (which I delete later) in the editor to help me think.
bananamerica 2y ago
I think more in terms of enjoyment than pure typing productivity. If I'm using a text editor that I found comfortable and fun, I am more likely to feel good while working. So a text editor is more like a chair -- the gain in productivity is indirect and maybe a little subjective.

meitham 2y ago

I don’t touch type and I’m fully with you on speed doesn’t increase performance, but I have recently started writing c# after two decades of python and man the number of lines that you have to write before you get to the meat of the logic! So I think that 10 lines of code are only to expressive languages not globally

MrJohz 2y ago
In fairness, I don't have so much experience with C#, but my experience with Java and OO-heavy JS codebases is that most of the boilerplate can be automated away without much problem - typing "cl<tab>" generates a class definition, and I can hit tab to jump between the different bits I need to fill in. With Copilot, this has become even easier because it is very good at guessing the relevant boilerplate to insert without needing to look through different options.
owenpalmer 2y ago
Learning to touch type is hard, but worth it. Once you learn, you'll realize the difference it makes.
- arunix 2y ago
  It need not be hard. I learnt over the Christmas holidays using Kaz (https://kaz-type.com/ https://kaz-type.com/)
neonsunset 2y ago
Could you post an example of the boilerplate you are facing with? I’m sure it’s something that's perfectly avoidable.

mikojan 2y ago

It is important to be sufficiently fast at editing or else you will not revise what you wrote. I hear people complaining a lot: "This is tedious. That is tedious." They have no control over their development environments. They write code once and whatever was produced in the process will be checked-in as is. It is aggravating because there is this sentiment that it is fine to be incompetent. It is not.

lawn 2y ago

I think typing speed is important during bursts. If you can type out a function name really quickly (autocomplete also helps of course) then you can continue your thought process with less interruption than if you were slower. > 90% of software development happens in the mind. The small amount of time spent actually writing it out seems kinda silly to optimize for. So you're saying that 10% is spent typing, which doesn't seem a silly amount to optimize for?

wokwokwok 2y ago
Yes, quite so, but it probably has almost nothing to do with absolute typing speed. There’s a marginal difference between an editor where you can type quickly and one where you can only type fast. We’re not talking about the difference between 300 wpm and 10 wpm. I bet if you measured, you would see, at best, a marginal difference between the speed of input between editors. Ie. The point is that, that marginal difference probably has no meaningful difference in your productivity. What makes the difference is probably how it affects, for example; flow. If your flow is interrupted by the editor hanging or waiting for some bs lang server lag, or having to update a vim plugin, you are being interrupted. …and studies show that interruptions do have a meaningful impact on productivity. This is why editors that let you type fast do not improve productivity for everyone. Some people get flow in other ways. Fast typing is not a universal metric for productivity, and it’s absolutely a diminishing returns thing to optimise for. It’s probably fair to say that if you have a moderately fast editor, going to a super fast editor makes no difference to most people. …but going from an editor that freezes or forces you to spend your time upgrading plugins, probably does; because interruptions like that are probably universal flow destroyers.

Zambyte 2y ago

> 90% of software development happens in the mind. Why? The only reason I can think of for this to be true is when there is high risk in writing wrong code. For example, long compile times leading to a large sunken cost, or a lack of testing processes. Unless you're doing R&D, only spending 10% of your "coding" time actually writing code seems very low, and you should try to optimize the processes that are lacking.

bvrmn 2y ago
I personally have a pipeline of multiple tasks I'm thinking about in background. It easily could take a week to get details in my brain. During coding I get already worked out tasks. Most of the time it's a final design. My colleagues considers me as a 10x developer. 10% coding looks very real in my case.
empthought 2y ago
The highest risk in writing code is that the code written will have a negative value; i.e. it will incur more development cost over its lifetime than it will recoup via its intended effects. Hastily written, poorly justified or reasoned code has a much higher likelihood of having this flaw, so that’s why I would say you are wrong about this.

MaysonL 2y ago

I tend to keyboard minimalism myself: doing as little typing as is required to produce the code. I.e.: lots of keyboard macros. Thus reducing the cognitive load of typing to a minimum.

lelanthran 2y ago

> The average developer averages 10 lines of finished code per day. And even with a raw 10x that amount to account for variance, changes, debugging etc, you'd be at 12 lines PER HOUR. Being generous at a full 80 chars per line, you have a maximum of 1000 keypresses per hour, or an average of one every 3 seconds. Even doubling your typing speed or keyboard response time would have no discernible effect. Just my personal experience, it's not about how fast I can get my ideas down in writing (whether code or not), it's about how often I am broken out of the flow when typing. At one extreme, using your stats above of "10 finished lines of code per day", you could argue that using this keyboard (https://www.youtube.com/watch?v=9BnLbv6QYcA https://www.youtube.com/watch?v=9BnLbv6QYcA) should have no effect on your productivity, and yet no developer would make or support this argument. Small frictions add up; there's a joelonsoftware post that I read a long time ago about this[1], and it stuck for 24 years! The best editor/environment is the one that gets out of my way. One where I don't need to look things up on google. One in which I have already learned all the shortcuts, and don't need to relearn them to make the software useful. Emacs `M-x sql-connect` is much easier for me to do than to look up, in VS Code, what shortcut has been assigned to the extension I use that does the same thing, and then look it up again in a few years when that extension is no longer supported. Same for Vim commands. Using VS Code, or a full-fledged IDE[2] removes the whole command interface: I now need to remember dozens of key-chords, not a handful of verbs and a handful of nouns. I need to remember which menu, and which submenu needs to be clicked. Each time I want to do something in the IDE I switch focus from the code to the IDE. When in Vim or Emacs, that never happens! The "keyboard maximalism" isn't about speed == productivity, IME. It's about "friction == disruption". -------------------------------------------- [1] From https://www.joelonsoftware.com/2000/04/10/controlling-your-environment-makes-you-happy/ https://www.joelonsoftware.com/2000/04/10/controlling-your-e... > So that’s what days were like. A bunch of tiny frustrations, and a bunch of tiny successes. But they added up. Even something which seems like a tiny, inconsequential frustration affects your mood. Your emotions don’t seem to care about the magnitude of the event, only the quality. > And I started to learn that the days when I was happiest were the days with lots of small successes and few small frustrations. [2] Which I use daily, btw. I'm not knocking the developers who use IDEs.

ReleaseCandidat 2y ago

owenpalmer 2y ago

> The average developer averages 10 lines of finished code per day This is a ridiculous statement. Citation needed.

Asraelite 2y ago
This is a relatively widely known claim, https://stackoverflow.com/questions/966800/mythical-man-month-10-lines-per-developer-day-how-close-on-large-projects https://stackoverflow.com/questions/966800/mythical-man-mont... It's debatable how accurate it is, but I think the ultimate productivity of developers is actually surprisingly lower than you would think.
skitter 2y ago
According to Stroustrup & co, it's less: They see a good dev optimistically writing 2k lines of finished non-test code a year, and that's when rewriting code ¹, so that checks out! (To be clear, I'm joking and agree with your sentiment, but they really did say that in an official reply to the US gov) ¹: https://downloads.regulations.gov/ONCD-2023-0002-0020/attachment_1.pdf https://downloads.regulations.gov/ONCD-2023-0002-0020/attach...
Jare 2y ago
Hopefully it's clear that: - code is not the only output produced by a developer. Communication, design, documentation, testing and tests, diagnosing and debugging, etc. - I can and do write hundreds of lines of working code in a given day (and I'm not an IC). But "finished" was meant to describe something that doesn't get touched again unless new work requires it. A lot of code today is written more iteratively, with mvps, experiments, baselining, refactoring, etc. An mvp is not (yet) finished. - 10 lines may be a low estimate today, but 100 is probably fair. (yeah varies a lot with language, boilerplate, etc) I hope the general agreement would be that the amount of characters of code written is definitely not the largest part of a developer's output, but reaching the point where a given line of code is "finished" involves a number of processes and lot of typing. And editors are an important part of many of those processes.
- kstenerud 2y ago

kamaal 2y ago

>>I've not once held a job where my keyboard speed had a noticeable effect on my productivity. Features like vim/emacs macros do way than increasing the speed of accomplishing a task. They are a way of converting O(n^k) manual tasks to a O(1) task. These are ways of doing lots of work in fewer steps. This is if your work involves lots of text heavy lifting tasks. Speed many times is just a unintended but a welcome side effect. Real value is in not doing manual drudgery.

wtcactus 2y ago

I think this is a gross generalization. In my present work at DevOps, I could say it’s true IF we only look at code. When I was doing computational intensive simulations, I would write clearly 100 or more lines of code everyday.

hydroteur 2y ago

It depends on what you work with. If you debug a complex issue you need to check many different setups to see whether your suspicions are right. Then, having a nice workflow where you sticky edit and run your code is quite important. It's not always the case. Quite often the only way to investigate the issue is to run a cloud workload that takes several minutes to start. Still, if you write good code, you can try to isolate the issue for local debugging at some point.

svlasov 2y ago

If you know what you want to build, typing becomes a real bottleneck.

vaylian 2y ago
Plus, the more ground you can cover until someone interrupts you, the better.

kombine 2y ago

This is partly true, but there is a caveat: it's 10 lines of finished. In order to get there you would write and edit this piece of code many times over until it reaches the desired quality. And VIM is meant for "editing" code.

krig 2y ago

It’s not just about typing out code even though being able to do that quickly is more valuable than you realize. There are plenty of other areas where typing efficiently facilitates thinking about software. - Writing clear notes and design documents helps in developing ideas. - Writing documentation. - Writing commit messages and issue descriptions. - Writing emails and messages when communicating with others. Typing efficiently is only one factor here, communicating clearly and efficiently, reading comprehension… these are also important. But typing slowly impedes development of those related skills as well.

GuB-42 2y ago

It is true that most part of software development happens in the mind, but sometimes, the mind needs a support. Some use a pen and paper, some use specialized software, but for many, the text editor is that support. That's where they throw their ideas, sometimes in code, sometimes as a comment, or in a scrap file. Seen as a support it is important for the text editor to be as unobtrusive and responsive as possible, to not break the thread of thoughts. And slowness, even micro-stutters do that. Mastering the keyboard, which include knowing shortcuts, touch typing and generally typing fast also helps, so you think more about the problem and less about the keyboard when writing down your ideas. Now, if the way you code looks like you are meditating in front of the screen, not typing anything but the final solution, and I am sure some people do, then you probably don't need to work fast in the editor. To each his own, but personally, speed is an important factor in choosing a text editor. That's why I am currently on Sublime Text and not VS Code. Even though the latter is similar but free, more popular, and with interesting features, Sublime Text is faster, and I like speed. And may take a look at Zed, now that it is available on Linux.

dimal 2y ago

I agree that 90% of software development happens in the mind, but also that being a keyboard maximalist makes sense, at least for me. First of all, there’s the ease with which I can get those ideas out of my mind and into working code. If I’m fiddling with a mouse and dragging things around in some virtual 2D space, it adds cognitive load and puts my mind in the wrong mode for coding. When I’m editing in vim, it’s easy to get into flow. There’s also the case that when I’m planning my solution, I’m also using a text editor with vim bindings, so I can get into the same flow state more easily as I’m doing software design. And even though a coder might only produce an average of ten lines of code per day, that doesn’t mean I’m producing 10 lines each day. Some days I produce none, and other days I produce a hundred, so it makes sense to optimize for the days when I’m producing a hundred. Beyond that, even the idea of producing a line of code seems to assume that you’re only writing new code. I’d say that 70-80% of my coding is refactoring. I’m either refactoring existing code or refactoring the code I’m writing as I go. The ten lines I write in a given day may have been written as thirty lines in the first draft, then edited down. So, again, optimizing for flow here makes sense.

damnever 2y ago

I have to disagree; average is not a good way to measure. I have written approximately 6,000 lines of code (including empty lines but excluding some generated code) over the past few weeks. Yes, I write design documents before coding, and most of the code is completed within a few days. I definitely spend a lot of time debugging, but almost all of those activities have been constrained to code. Test cases are very helpful in making the process clean. I use Neovim inside iTerm2, so all those activities are done within terminal. By maximizing productivity through the use of the keyboard, I can eliminate many dependencies, such as the mouse and multiple displays. I believe dependencies are a source of distractions. Most importantly, writing helps thinking. When I am stuck, I just write random comments (which I delete later) in the editor to help me think.

bananamerica 2y ago

I think more in terms of enjoyment than pure typing productivity. If I'm using a text editor that I found comfortable and fun, I am more likely to feel good while working. So a text editor is more like a chair -- the gain in productivity is indirect and maybe a little subjective.