Comment by kstenerud
1 year ago
> 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.
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.
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.
> The average developer averages 10 lines of finished code per day
This is a ridiculous statement. Citation needed.
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/attach...
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.
Hmm... This might be where my process differs, I guess?
In my normal process (not exploratory work), I don't write a single character until I'm sure of how the thing I'm making will fit into the overall design (such as the API it will have, how it will interact with other components, its placement in the overall architecture, what its responsibilities are and how to structure it so as to minimize potential confusion and make what it is doing clear to a reader, mentally walking through code paths to make sure other components can use it as intended, etc). All of that happens in my head, not in an editor (although I might have a few notes jotted down if it's a big change or a whole new feature).
Then, once I know exactly what I intend to write, I just dump it all down into the source files. 80% of it is already "finished code" in that I won't be changing it again unless I've made a serious design error.
1 reply →
This is a relatively widely known claim, 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.
Last I saw, the stat was 40ish per day. It's partially testable though. You presumably have a codebase at hand with a few contributors. Just git stat that code and average the lines changed by the top 5 contributors. Count deletions as "finished" lines of code too. Add in some auto-generated lockfiles and whatnot if you still haven't hit that 40 line-per-day mark. Report back if you're able to exceed it.
> This is a ridiculous statement
Ten lines per day?? Over my 20-year career in Big Tech I figure I've averaged about 10 lines of shipping code per week. I've been working in a domain-specific field and have shipped several kernel features. These days I'll sometimes go an entire quarter without writing a single line of code.
Not all of us went down the "Java code monkey" career path.
> I'll sometimes go an entire quarter without writing a single line of code
Then you're not a programmer anymore, you're something else.
1 reply →
I work on big tech and average far more lines of production code per day because where my project falls on this spectrum. The biggest thing that I've seen slow things down is scale (both size of codebase as well as users), followed by testing culture. This and a few other factors dictate the rate at which you invest in feature development. Not everything is a heavily undertested behemoth that has hundreds of millions of users. Therefore your experience may differ greatly from others and that means no one has the right experience. Even different roles within an organization making a common product can experience great variance based on subdivision (infra vs platform vs product vs security, seniority, etc).
>finished code
I think the commenter suggests that you can just write those right away and the 100s of lines along the way don't exist
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?
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.
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.
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.
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.
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
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.
Learning to touch type is hard, but worth it. Once you learn, you'll realize the difference it makes.
It need not be hard. I learnt over the Christmas holidays using Kaz (https://kaz-type.com/)
Could you post an example of the boilerplate you are facing with? I’m sure it’s something that's perfectly avoidable.
>>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.
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.
> 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) 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-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.
> 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
And the knowledge of `M-x sql-connect` came to you how? In a dream? Commands in Emacs are undiscoverable unless you know what to look for.
> 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!
No. It happens only because you're used to Emacs and Vim, and unused to an IDE.
> So that’s what days were like. A bunch of tiny frustrations, and a bunch of tiny successes. But they added up.
And those frustrations are rampant in the Emacs/Vim world. People pretend they are not there because of this false notion that only those two are the sign of a great programmer.
By the time I've done my coding, project-wide refactoring, and looked up half of a project's code most Emacsers/Vimers are still stuck trying to find all references with a full-text search.
There's a reason VSCode's LSP took the world by storm
> And the knowledge of `M-x sql-connect` came to you how? In a dream? Commands in Emacs are undiscoverable unless you know what to look for.
It's one command that implements autocomplete which gives you access to the entire system.
> It happens only because you're used to Emacs and Vim,
That's my entire point! I learned the majority of Emacs and Vim commands well back in the mid-90s.
> and unused to an IDE.
Objectively not true, if you had read the entire comment.
> People pretend they are not there because of this false notion that only those two are the sign of a great programmer.
I think you have a chip on your shoulder about this. You read my post as some sort of attack on IDEs so responded with an attack of your own.
My point was about little frictions all adding up. Sure, there's a steep learning curve in learning a programmable editor, but you only climb that curve once.
It just takes much less memory to remember 4 verbs and maybe 6 nouns in Vim to perform navigation, than learning 4x6=24 shortcuts for similar functionality in Jetbrains/Eclipse/Vs/VSCode/etc.
I'm just explaining why needing to remember fewer things is the path of least resistance for me; whatever argument you are talking about involving signs of great programmers is beyond the scope of what I am saying.
7 replies →
> 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 [...]
> removes the whole command interface
`C-shift-P` works the same in VS Code (and other editors) as `M-x` in Emacs. VS Code (and many other Editors, like Sublime Text) has the same "keyboard only" usage possibility as Emacs.
I've switched from Emacs (after more than 20 years) to VS Code to Sublime Text and did not need to change my habits. And to be honest, Sublime Merge is what Magit always wanted to be, a useful combination of GUI (for the "easy stuff") and a textual interface for git.
> `C-shift-P` works the same in VS Code (and other editors) as `M-x` in Emacs.
I slightly disagree with this assertion. I upvoted you anyway because I think it's mostly correct for those who aren't full into Emacs :-)
My reason for disagreement: `M-x` in Emacs gives you access to every single thing that the editor can do (like the function to move the point forward with `forward-char`). The `C-s-p` in VSCode doesn't give you the same.
2 replies →
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.
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.
> 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.
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.
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.
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.
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.
If you know what you want to build, typing becomes a real bottleneck.
Plus, the more ground you can cover until someone interrupts you, the better.