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.
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...
[2] Which I use daily, btw. I'm not knocking the developers who use IDEs.
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.
No. It happens only because you're used to Emacs and Vim, and unused to an IDE.
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
It's one command that implements autocomplete which gives you access to the entire system.
That's my entire point! I learned the majority of Emacs and Vim commands well back in the mid-90s.
Objectively not true, if you had read the entire comment.
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.
And you know this command how? You discovered it how?
Indeed. And now you complain about friction in IDEs because you refuse to learn IDEs to the same extent.
Yes, yes they do. And I find there are significantly more frictions in Emacs and Vim than in a modern IDE. The only reason you don't see them is that you've already learned Emacs/Vim
Wat. I don't even know what these random numbers mean, and where you got them from. And how we went from functionality and capabilities to navigation.
Thing is, you don't remember "fewer things" with Emacs/Vim. You end up remembering about the same, or greater number of things on top of significantly worse functionality.
Like you pretend that remembering dozens of various commands to type into `M-x` is somehow easier, and requires less memory than remembering the common shortcuts for common actions and falling back to Cmd+P(VS Code)/Cmd+Shift+A(Intelli J) to look up actions you rarely use.
Why the antagonism? Programmable editors don't work for you, fine.
Why make personal attacks on me, like this:
I'm not pretending anything.
Not true. Like I said, I use an IDE daily, and there's much more to remember to get the same functionality that I get out of (for example) Vim. It's easier for me to remember (for example) 10 nouns that can be combined with 10 verbs than to memorise 100 shortcuts.
You may find it easier to memorise 100 shortcuts rather than 10 verbs and 10 nouns, but I am certainly not pretending when I tell you that I find it easier to remember 20 things rather than 100 things.
1. There are no nouns or verbs in Vim. There's a haphazardly built combination of letters that are laboriously explained as some grand design.
2. You keep coming up with random numbers that make no sense and pretend (yes, pretend) that they are somehow true and relevant
I didn't memorise 100 shortcuts.
The only reason you struggle to get the same functionality out of an IDE is that you don't want to invest as much time and energy into learning it as you did with emacs/vim. There's nothing inherently easier about memorising `M-x sql-connect` or 20 random letters in Vim than learning basic functionality and shortcuts of an IDE.
I agree. Honestly, I’m proficient with vim/emacs, but I’ve been using JetBrains for ~13 years and don’t want to sound boastful, but I’m pretty sure I’ll run circles around non-trivial amount of vim users in terms of productivity/efficiency/raw text editing. The amount of time I’ve put in customizing my workflow is stupid. The false dichotomy that if you use IDE you must be point-clicking around menus is often repeated. I guess … know your tool of choice inside-out is what’s more important.
Yes, there is.
Since your entire argument is predicated on a false premise, maybe you should stop digging at this point?
You don't understand vim yet you confidently state that it requires remembering more things. vim is like a language. You do not memorize entire English sentences when you choose to communicate with someone, it's the same in vim. You do not memorize how to do do something, but rather the grammar/verbs/nouns.
If you know that 'd' is the verb for deleting, and that 'w' is the motion for 'word', you can combine them into 'dw' to delete until the end of the word. When you later learn that '$' takes you to the end of the line, you know that you can do 'd$' to delete until the end of the line. You do not need to memorize 'd$' and 'dw' individually, just the motions and actions separately.
The same applies to actions, when you learn that y is yank (copy), you can apply the same 'w' and '$' motions in that cases to copy until the end of the word/line. That is what the poster means about verbs and nouns. Vim isn't discoverable, you cannot learn to use it without reading. But it is the most logically consistent "editing language" I have personally seen (alongside kakoune/helix).
You are also mixing up many concepts in your arguments. You can get LSP in vim/emacs and you can get vim-ish hotkeys in popular IDE's. The topic of this thread, Zed, is pretty vimmy and is closer to vs-code than it is to vim.
As if that doesn't require you to remember things. In the end I always, without fail, see people consistently struggle with doing things in Vim that take a single shortcut (or an action lookup) in an IDE. Even people who've been working in Vim for years.
Because it's a nice little story about "oh, it's so easy to yank a word" because it's always easy to come up with the most trivial examples.
And this narrative about verbs and nouns falls apart even for trivial examples. E.g. the simple act of going to end of line, end of file, beginning of file are three different shortcuts that have little to no relation to each other. No worries, you just have to memorize them. Don't forget variations on shortcuts like yy and Y. And many other idiosyncrasies that don't fall neatly into the verb-noun narrative.
Funny how the very same people who say this are hell bent on never learning IDEs.
Yes, you can. There's a reason LSP never came out of emacs/vim world.
`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.
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.
As long as we're being pedantic: M-x only gives access to every single interactive function (which means every function which has the `(interactive)` statement). I can't speak as how to that relates to Microsoft VS Code's 'C-s-p' though.
There's M-:
This is a ridiculous statement. Citation needed.
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.
My process is in that case quite different. When working in Python I’ll typically write thousands of tiny snippets of code directly in the interpreter to check that simple things work as I expect. Those are gradually distilled into parts of a .py file with accompanying pytest tests. Then those are refactored into classes and separate files as needed. Overall, I think I type and edit way more than you :)
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...
I think the commenter suggests that you can just write those right away and the 100s of lines along the way don't exist
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.
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
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.
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.
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.
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 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.
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.
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.
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.
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 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.
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.
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.
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 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.
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.
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.