Carmack on not being a power editor user

I think arguments about productivity miss the point and Carmack is actually right that typing speed isn't the bottleneck.

I think the reason programmers love to tinker with their vim or emacs configs is because it's simply satisfying. Just like a blacksmith has their very own set of valued tools, there's something extremely rewarding about configuring your setup just the way you want it. You work your entire life with it, so you might just as well make it your own, I think that's what people get out of it, just a subjective sense of making things fit right.

It's like my barber who has some cool vintage scissors he got from someone. Could he cut my hair with some high grade scissors he bought on the internet? Sure, but he likes his ones better. At the end of the day programming is more like a craft than a science and it shows when it comes to topics like this.

Responding to one of Carmack's follow-up tweets (https://twitter.com/ID_AA_Carmack/status/1302652989610618882):

> Yes, it can be very impressive watching people using the power tools to maximum advantage, and sometimes is can be a dramatic win, but I usually think that it adds up to... a few minutes saved a day?

I think measuring the gains of text editing features in terms of time is a distraction. Expressive editing features take something tedious and make it effortless. It makes it easy to do something that I'd normally put off.

But the reason text editing features end up not being that important is that if the task is mission critical, you'll end up just soldiering through, even if it's tedious. Therefore it's an incremental benefit not a revolutionary one.

I like text editing features because I personally like being organized, not because I feel like it makes me a more effective programmer. It lets me indulge myself in keeping code organized without that becoming a time sink.

So, I agree, somewhat.

I am a long-time Emacs user. Occasionally, editing/macros/etc can save a LOT of time, and makes it much easier to make some changes which I might not decide to do.

What I find more important however is the effective window/buffer management. Being able to manage my screen real-estate is killer; being able to do everything within one "world" is really valuable. One of the things I find most valuable is that I run my shell within Emacs. This lets me keep my flow going instead of switching context and perhaps getting distracted. I can watch the output of tests etc in one corner of my screen and edit files etc in the other ones. And because its quick to switch buffers, I can more easily reference various files for what I am doing.

Basically, the literal time it takes to type is not the big benefit, but that it allows me to reduce my cognitive overhead of doing everyday, boring things like resizing windows, looking up symbols/finding definitions etc. This makes it easier to focus on my task at hand and not get distracted by all of the mundane tasks I would need to do otherwise.

Carmack would be far more convincing if he could have said something like "I was once a power user of vim/emacs but I went back to programming in nano because I didn't need all those features."

Somehow I never hear anybody say that.

As a long time user of both vim and emacs, I find it intensely painful to watch some seasoned programmers tediously mouse their way through mountains of text.

I often think to myself, "ok, you've just taken half an hour to do what I could have done in less than a minute."

Honestly, I have better things to do with my time than edit text, and when I do edit text I want to get the maximum accomplished in the minimum amount of time so I can get on to the thousands of other things I want to do with my life.

Using a crippled editor or not taking advantage of editor features that could save you massive amounts of time, errors, and headaches runs directly contrary to that intention.

It's great that Carmack is satisfied with his own setup but in my case you'd have to pry my vim and emacs from my cold, dead fingers.

Something people often forget to consider when they talk about all the benefits of being an editor power user: how often they get distracted or go down rabbit holes when tweaking editor config or using advanced features. I've worked with people who seem to spend half their day on this stuff.

So while it can certainly be impressive to watch someone who has mastered their editor, I always secretly kind of doubt that it's really much of a productivity win for this reason.

I think there are huge wins for getting proficient with your editor (refactoring commands, debugger, etc. as John Carmack mentions), but sharply diminishing returns beyond that.

Having to use Xcode on MacOS recently reminded me how very much more productive my custom setup of Linux, Emacs, and Xmonad is.

Just one of reasons is the ease of code navigation, such as bringing some parts of code into view while keeping other parts visible, or not visible. I have it rigged up so well in Emacs that it doesn't distract me from my thinking of the actual problem.

A somewhat relevant story: One time, I was sitting on a park bench in my neighborhood, with a battered old laptop, doing some heavy semi-mechanical high-volume editing that didn't require much thinking. I was throwing a lot of rapid Emacs window management, isearch, ad hoc keyboard macros, etc. at it, and the task didn't require much second-guessing, which I suppose resulted in a lot of almost Hollywood-like "programming/hacking" rapidly changing windows of computer-y text on my screen, extend highlights flashing, syntax coloring updating, etc. At some point, some of the people who were arriving for a pickup soccer game in the park gathered round, and were just watching, and when I got to a stopping point, were kinda cheering and congratulating me (I think I didn't speak any of their languages), and one gave me a high-five. That brief moment of being nerdy-cool totally wouldn't have happened in notepad.exe, and, also, my task wouldn't have been tractable in that. (If I was using a lesser editor, I would've died of dehydration, as it took 10x to 1,000x as long, or blown out my hands from stupid mouse&keyboard RSI.)

(BTW, finding certain tools much more productive isn't due to an unwillingness to try new tools. I try new tools recreationally, and am also doing a complicated startup in which I have to do All The Things. But there are some tools I end up keeping going back to, after trying other things, because they really do seem to pay off in productivity.)

That said, apparently, the way Carmack personally uses editors, and what he gets from them, any old editor will work about as well as any other. And I'm not a snob about what works for me: I'd still hire Carmack, even if I saw him hunt&peck typing one-handed into notepad.exe in the interview. :) I'd guess there are other classes of tools in which he finds big wins in the details. Also, I know Carmack experiments with other tools, since he was even working with Racket/Scheme on Oculus for a while.

When people tell me stories about $EDITOR significantly improving their productivity, I wonder what kind of sweatshop coding they do where typing speed is a bottleneck...

I used to have a pretty nice emacs setup but this year I have been coding python in gedit (notepad.exe of Linux) and I've done just fine.

Btw, Carmack mention the debugger as an essential tool. That's my main issue developing C/C++ on Linux. I prefer working on Linux for many reasons but if there is a negative, that's it.

I found every debugger-editor integration to be terrible, at least compared to Visual Studio on Windows. gdb is very powerful, but its UI is primitive, and that includes tui. And most integration basically just assigns shortcuts to commands and show you the current line in the source file. Something as simple as stepping inside a function and watching local variables change can be a problem. Also, no "edit and continue". Someone will probably tell me that I am doing it wrong but if you do, please tell me what I can do to get a Visual Studio 6 level of experience.

Of course, I can get around it, the answer fits in one word: "printf". But I don't want it to be like that, it doesn't have to be, most good IDEs do it right. Note that I use gdb, but for me, it is the big gun, when other weapons have failed. Even for crashes, I tend to go with valgrind first if I can.

Typing for a programmer is like brake pedal technique for an F1 driver. Yes, it is important to be able to type effectively. No, it is not sufficient for being a good programmer.

It's easy to get lost in fancy editing techniques that get you a win of minutes per day (as Carmack mentions), while learning to come up with a better design will save you weeks in overall development time. Learning more editor shortcuts is much easier and more flashy, of course.

I’ve tried to force myself to pick up vim a few times but after getting a bit older I realized that I don’t want to become one with my machine as a fighter pilot might be with their plane. I like the distance the mouse move and click provides me. I do more thinking and reading than typing anyways

I find being good at vim makes exploration much easier though. Being able to use Ag to populate a quick fix list is way faster for me than ctrl-f plus clicking through every option. And being able to go up and down the movement stack let's me retrace how I navigated to where I am right now, in a way that isn't possible in many editors. Tools like just searching through open buffers let me use search in large codebases without having to wait forever for results. So for me being good at an editor is more than just being able to make fast edits (although that's definitely a benefit too).

And even if I only saved a few minutes a day, over several years that is a lot of time saved, without much investment. It's really easy to get started with vim, get comfortable with the basics in an hour or two, and then just get better by using it every day. Then you can slowly introduce features that save you time. Just setting up fzf and ag has probably saved me several minutes a day vs. using vscode search.

To be honest, learning power editors is mostly just an excuse to fiddle about at work without getting in trouble. The work's still visibly getting done and the bosses don't care if the UI keeps changing so it's a win for me.

In my experience; they DO come in handy! Some programming languages or file formats get very arsey about formatting and line endings. Sometimes you need to compare files in hexadecimal. Sometimes you need to mass find/replace. Maybe not everyday but it's good to have these tools on demand with the know-how to operate them.

One other BIG benefit of editors like vim and emacs or even notepad++ is that they start immediately, never lag and don't gobble all the ram. It has significantly improved my coding performance now that I can just open it on a whim without having to factor in if it'll slow my system to a crawl with the other current running programs.

This is such an odd perspective. Everyone here would say that the copy and paste shortcut keys are worth learning. Also alt-tab to cycle through windows.

So why is it so hard to believe that other shortcut keys are useful?

I have deep respect for Carmack. If he would rather spin his cycles to solve difficult problems, I respect that. To say that learning time saving shortcuts doesn't save time is shortsighted. If a woodworker chooses to work only with chisels, it doesn't make him less of an artist. However, to say using power tools doesn't make you more efficient is a tad disingenuous.

I’m always amazed how genuinely humble Carmack sounds.

One of the best programmers in his generation, yet he is always sharing what he’s learned, struggled with and is not particularly good at.

I use these features more when doing non programming tasks. Often I could use find/replace and some regex. However I enjoy the experience of having the editor do some of the lifting. I don't think I'm faster or better for it, just a little happier.

If by programming you make a computer do some work for you, it is strange to not program your programming tools, cause using them is work as well. For me, unautomated, repetitive editing and a lot of arrow key navigation is like walking in a swamp. I suspect it must be something with a thinking process, cause I can think without code, but cannot see much detail where the devil lives. If it is working code (or a sound data scheme, whatever) then there is something to discuss. Until that it is just an unpainted picture that is worth nothing. Also, maybe the amount of "no, you cannot do that this way here" plays a role in that. Or a fluidity of requirements. If you learned your area and requirements well, or you are the creator of these, then you know where the limits are in advance and just do the routine, no matter how hard it seems from the outside. But when you work with something new, on something unclear, the speed of a big change and the depth of concentration on it are crucial. Unimplemented idea is a tree of all possible, very similar code structures, of which most will fail, and if it is not write-only/write-once, you either have proper tools to transform it or slow down x10 or more. If you're a long time developer, then you know that feel "oh there it fails, but now it is so much keystroke to refactor this, so I will hack it here instead or just leave as is and pretend it's not a big deal". You know, and be honest, you did it many times.

That said, I'm not fiddling much with my configs, it's usually just vim and a lot of snippets like try<tab> -> try { } catch (error) { }, <F3> on an identifier for log.debug("varname:", varname) on the next line, gr for grepping it with default excludes, v%<action> to comment/copy/move a block, ma mA markers to not spoil my stm with file:lines and so on and so on + basic movement and regex. Nothing fancy or christmas like in these vscode plugins these days.

Emacs isn't better than Rstudio, Pycharm, TexMaker, and the other programs I would be using otherwise, but it is more comfortable and keeps me happy.

This distinction is important imo: https://twitter.com/danielhoffmann_/status/13026995532385280...

Carmack spends more time in algorithmic and less in churning code.

I personally spend a lot of time reviewing code and looking for bugs, and I wouldn’t be able to live without a feature to click through function definition. When I use Xcode to review objective C I feel like have super powers due to their caller hierarchy feature (which lets you quickly go through any of the callers up the stack). When I review other code with other IDE I feel disabled. Unfortunately I spent very little time using Xcode in my career.

I started using Emacs simply because there was no other editor or IDE which had good Clojure (my language of choice at the time) support.

After a while, I started noticing how sluggish IDE’s and electron-based editors are.

I’m now a vim user, but my most used features are «intellisense», go to definition, find references and ctrl-p. I guess these are the things Carmack refers to being of value? I also appriciate spending less time moving my right hand between my keyboard and trackpad for ergonomic reasons.

In addition, I have a more snappy editor than most of my colleagues.

What I don’t have is a good integrated debugger or refactoring support. The latter i never made much use of anyway and the former i’ve never minded being a seperate tool.

Flip side of this is that being a power cli user in 2020 is more powerful than ever before! Recently saw an interactive quantum circuit visualizer in 100% text mode. And its getting me personally back into old school favs like lynx, irssi ;)

I'm probably a vim power user, but I stopped adding to my knowledge years ago because nothing seemed to be adding to my productivity. It sounds like Carmack just hit that point earlier.

I feel this way about version control systems. More trouble than they are worth to me, even when working in the same tree with many others. If I make a branch, it's only because that's the only way to submit a PR. Merge conflict? I'll look at my diff and apply it manually to the other side. Merkle trees are great, but the only useful history to me is a straight line!

I suspect the majority of programmers who say this have internalized the core api features they depend on (function calls, syntax, common algorithms, etc.) that make them super productive. Whereas average programmers and below need all the help they can get from their editor to tame the wild goose chase of looking up common functions, scouring StackOverflow, and even looking for random snippets on long abandoned blogs, etc.

In other words his mastery greatly reduces his dependence on IDE/editor features so this makes perfect sense.

Watching Carmack live coding, he types with conviction and gets things done:

https://www.youtube.com/watch?v=ydyztGZnbNs

Sitting down with OpenBSD during a cabin retreat:

https://www.phoronix.com/scan.php?page=news_item&px=Carmack-...

I think the best case to be made for learning how to use a "power editor" is that editing text "manually" can sometimes be seriously disruptive to your flow. If I can do a regex replace-all with vim, I get to go back to thinking about my real problems much more quickly than I would if I had to hand-edit.

The tons of time multi line editing saved me so I don’t have to look like a moron adding a chat to each line doing a lord of dance finger tap on the keyboard.

The basics will certainly double your speed and I say this as I train a junior person. Quick tab switching, all the copy and paste stuff, etc. The rest in my opinion of over engineering half the time and preparing for moments that might not even happen. Certainly evaluate any movement or motion you do all day and look into optimizing. I mostly learned vim And vim keys for sublime because I wanted to be more enjoyable to be watched when I code and not have so many staggering mouse moments. I’ll probably forget everything in 3 years and go back to the the basics and a mouse.

Typing isn't the bottleneck for coding sure. But time wasted on text editing, especially mechanical/repetitious nonsense, is valuable keyboard time stolen from any more productive computing chores of which I have a seemingly endless supply of.

That’s always how I felt. Like 20% of my job is writing code. The rest is social and design work and documentation.

But I think there are people whose job involves cranking out code all the time and I can see why it matters to them.

“I laugh out loud when my kids get giddy about little features of their car like turn signals and breaks.” -somebody who thinks that it’s not worth the effort to learn how to use the tools they use every day

I learned a similar lesson about typing speed. I learned, then developed and practiced a custom keyboard layout to make my typing faster and with less strain. In the process I realized that the amount of typing I do while developing software wasn't even enough to relearn to type and I had to practice separately just for the volume. For the strain part, also learned that the way the keys are hit/pressed is for more a factor than actual key positions.

I agree, in general, with his point. But multiline editing was a real game changer for me. Things I once did manually that can be achieved with significantly less tedium.

I find Sublimes "power" features really useful for the tangential stuff. Getting a good look at a JSON object, preparing some mock data, preparing one-off data. Basically everything that falls before the threshold of being worth automating or writing a script for. With multi-line edit and a couple of plugins you can do some "excel" like stuff without the overhead and with the simplicity that plain text brings.

There’s an age factor here, or maybe a certain phase in programmers’ growth (which sometimes they can cycle back into).

I am not that old, but I am old enough to remember a time when I was really into those power features. Over time you get burned by having to change platforms during career evolution, you get other things taking up your spare bandwidth, and you get slower.

Now learning the power user features just doesn’t have the same appeal

I was never a Fan of Shooters...but i really love that guy. He is THE example of a decent "superstar" developer without BS.

I've used Emacs since forever ago. I don't bling it out with Spacemacs, Doom, or any of the other things people install these days. I sound/feel like a boomer railing against kids with their Minecrafting and Roblocks and social medias. But the point is, my Emacs workflow is reflective of the fact that I don't use Emacs because it gives me some huge needed leverage over the act of writing code. That is relatively straightforward, and the plain Emacs bindings, once learned, are more than suitable to the task.

Rather, I use Emacs because of a combination of pain points that it simply handles better than other editors, that add up to a significant advantage:

* Emacs does electric indent "right". Other editors will attempt to indent automatically, but the tab key always means "insert tab", not "indent this line to its computed indent level". This alone makes it more pleasant to use than most "modern" code editors.

* By default, Emacs will help you match paired delimiters (parens, brackets, quotes, etc.) but will not insert closing delimiters. This saves me that awkward experience of typing out a code block, parameter list, or string constant, only to find that I now have mismatched delimiters because I didn't realize I was supposed to cursor over the closing delimiter my editor oh-so-helpfully provided rather than type it myself. Except some editors just cursor over the closing delimiter if it senses that you're typing the delimiter at point. Some don't, though, and it's hard to remember which is which!

* I work a lot in Lisp, and Emacs is better suited to handling Lisp code than most other editors.

* Emacs is an immensely useful programming environment. There are applications like Magit and Org-mode built on top of Emacs that are just stupid useful workflow grease. On top of that, if there are pain points in my workflow, coding something up in Emacs Lisp to handle them is incredibly easy and straightforward, and I can evaluate and test my code right in my running Emacs session. Contrary to popular belief, Emacs integrates well with Unix tooling; Unix tools can be easily plumbed together with Emacs buffers, enabling you to use Emacs as a kind of "super-shell" to capture, move, examine, and massage data.

I just signed up for https://repl.it/

I’d like to kick back on my couch and code for an hour using my iPad and Apple Pencil.

I’m anxiously awaiting for someone to image a better mobile experience rather than attaching a hardware keyboard.

Not sure I agree. I've been paying for a personal license of Visual Assist for a few years now. The power editing features I'm getting from it are really good, save me a lot of time. The "rename identifier" feature alone justifies the cost for me.

I am slow typist and really lazy at exploring all the possibilities of modern text editors/IDEs. Well except of intellisense which I consider absolutely invaluable. Still I do not feel it ever held me back when programming.

In JavaScript, I often had to solve bugs and traced logic through 40+ source files. The reason I learned some editor power features was just to be able to navigate files quickly. For continuity of thought, I found it valuable

Could someone paste Carmack's twit here?

I can't seem to see it without enabling javascript.

tbh the main use I have for a text editor is comparing files

I've been using vim/vi for decades, and am constantly referred to as the 'vim guru' in my dev sphere - but I only know like, 5 basic things - editing/navigation, search/replace, window management, cscope integration and .. Termdebug. The magic, though, is knowing how to access the command history window .. for some reason this always gets oohs and aahs.

For me, Termdebug is the killer feature. There's something about being able to debug things faster than the other IDE-using folks, who are usually just waiting for the spin-up of their IDE into debug mode to stop by the time I've already stepped through the code in focus ..

I think a lot of people would be in the vim camp if they could just master the 5 basic operations they'd need to use vim. Its pretty interesting to discover the whole world of stuff in help.txt that I just never, ever touch, for whatever reason ..

Yeah, if you amortize your coding output over a significant period of time, it'll be like a couple hundred lines a day at most. In fact, even as few as 200 lines would likely put your in the upper decile of programmers as measured in LOCs/day. I didn't believe this actually, but at Google there's a dashboard where you can look at your (and everyone else's) stats wrt lines added/deleted/changed, and it doesn't lie.

The point being, you could easily type this many lines per day using Morse code.

That said, I think Carmack is being overly dismissive here. Sometimes you end up in a situation where not knowing (or having) certain editor features results in a ton of tedious manual editing. I know a few tricks to avoid those situations in my work, and have a few bookmarks to help with the rest. I think this is the right balance to have - do know features which you find use for at least once a month, even if they are obscure, and know where to find the rest.

I hope HN will shut up about Vim and Emacs now

IMO, That kind of crushes any argument about the tool you use, other than your brain.

Carmack is...a special case.

The reason why being blindingly fast in tmux/emacs/vim/shell/etc. is a difference in kind rather than degree is because it lowers the activation energy on trying radically different things. If you can move massive amounts of code around quickly and accurately you can try a different design on a whim, and throw it all away without a second thought if it doesn’t work out.

When manipulating code is time consuming there is a tendency to “make it work” with the design you’ve got. So much code looks like someone “made it work”.