> 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.
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)
- 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.
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.
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 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.
>>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".
> 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
> 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.
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.
But as their focus has shifted to building Collaboration & AI features, and still haven’t yet nailed just being a good/great base editor, its become less useful to me.
I still have a lot of hope for Zed.
But for the time being, I’ve switched back to my old editor & IDE … and I’ll try Zed again at a much later date.
Except, as I understand it, the collaboration features were one of the primary things they wanted to do with Zed. So this isn't a case of bloat. The first blog post on the site is "How CRDTs make multiplayer text editing part of Zed's DNA".
I'm still happy with vim/nvim as daily work tools (also currently exploring kakoune and helix... because why not).
Think of vim/nvim setup as a one time process: a bit complicated, but once done then you are ready to go. Of course, I use text editors for... code editing. No need to turn it into an IDE or mail client or whatever.
I don’t follow. The collaboration features have been part of Zed from day one. The recent addition of chat feels more like something the team wanted to use itself, so they never have to leave the editor any more, not a core focus of development.
Really my own issue with Zed is the crummy TS language server integration. Everything else is fantastic.
I would like some form of built in diffing, but for simple conflicts this is fine.
Seconded. I'm loving the Zed experience, but having Javascript features provided by the TS language server gives a really bad experience; if I fat-finger a bracket then I get a bunch of TS errors about missing TS stuff littering the code, even though I'm not writing TS.
It's not a deal-breaker, but it is really annoying - I have to find the problem myself with no assistance from the language server. In fact, with hindrance from the language server because it's littering the code with completely spurious warnings of irrelevant "errors" that aren't.
I haven't tried coding in TS on Zed, so I can't comment on how the actual TS experience is.
Doesn't highlight Perl so I'll pass until it does. Looks snappy otherwise. Back to VSCodium, I guess.
Collaboration, AI, chat, couldn't care less. Hopefully they can be disabled. I used Atom for a few years before they discontinued it. Yes, it was quite sluggish but otherwise it was usable, it had multiline editing and other sublime-isms, so I didn't have learn how to use an entirely new editor. If Zed can replace Sublime, Atom or VSCode for me that's great, otherwise I'll pass. I'm only using the basic code editor features, no git, no collaboration, no integrated terminal, no nonsense. Multiple cursors, PCRE matching and dark theme (preferably molokay) are a must.
There are many great editors out there, some free some not. If a newcomer wants to break into the market, they need to add something new to the table. Understandably, in this day and age, it might be AI. Plus, they need to find a way to make money, offering collaboration and AI related feature might enable that.
I tried Zed for one day, without collaboration or AI enabled. It has some un-rounded edges, for example, the scroll bar in some window frame don't even work, but I can still get some job done with it. I use VS Code daily, Zed reminded me how a faster and snappy interface should make me feel. I hope Zed succeed.
Zed also hastily went to v1. Simple things are missing such as labels to identify where a conpletion It's coming from when there are multiple completions with the same name. Also typescript types which are updated by an external process do not reflect unlike vscode.
They are now trying to do collaboration with ai to return money to investors but again nobody wants this.
That's why most editing tools should be open source and done by people passionate about it. The only company that managed to do paid editoes well is Jetbrains because their IDEs are actually much much better than the competition and much better than Zed.
Since many here are complaining about this, I’ll jump in here to say the contrary.
I love the AI integration in Zed, it’s really smooth, pleasant to use, and well-integrated. I have a good experience pairing it with Sonnet 3.5.
The REPL feature is great as well and I totally see myself using that.
I agree on the collaboration bit though. I understand it’s one of the original premises and goals of Zed, however in order for it to really work well, I think you’d need to get everybody in your company to use Zed… which is honestly a “pretty tough” sell. I could imagine it making more sense if they had IntelliJ and VSCode plugins integrated with it, so the adoption could be more incremental.
That said, I agree that I definitely miss e.g. debugging support.
I think the trick of text editors/note apps has become such that every few years you have to look for something else. Especially the note apps - either it dies, or bloats up, or these days more often goes subscription route ALONG WITH other negatives.
A lot of editors are being discussed here but I see nobody has mentioned Kate (KDE's Advanced Text Editor) [1] in the conversation yet, so I'm doing it. Kate is a very mature and capable editor, and even if I only use it on Linux I'm glad to know that it is also available on macOS and Windows. It natively supports LSP and has much, much more to offer in terms of project management, support for build system, support for working with Git (it's actually the only Git GUI that I found to be usable), SQL databases integration, and of course, advanced editing features. I started using it a few years back after a very long text editor journey: on Windows a bit more than 20 years ago: Notepad, HAPedit, then Notepad++ ; then I got a Mac and used TextMate (which introduced me to powerful text editors) for a few years ; then I switched to Linux ~15 years ago and used Gedit for a few months before diving head deep into Emacs and stayed fully there for… 12+ years (I actually still use it from time to time, but it's less and less the case and most importantly I stopped doing everything in it including my email, social networking, IRC, etc.) ; and now for a few years I've mainly been using Kate (and Kwrite for quick edits + Nano [2] in the terminal or on remote hosts). I even contributed a few features [3] to the project, KDE developers are very welcoming!
[2] I must say here too that Nano is actually an underappreciated gem. It supports a lot more features than people generally imagine: syntax hilighting, line numbering, auto-indent, multi buffers, mouse support, keyboard macros, … it's actually a decent simple code editor!
I agree that Kate is a good code editor. I have tried more than a year ago when I still use KDE Plasma (now switched to Gnome). Honestly, I am happy that there is at least one GUI Code Editor from a big community that actually on par with some popular code editor (VS Code, Sublime, etc). Because I see that most code editors made by the Linux community are always lacking in features when compared to other popular code editors.
However, there are some things that make me not use Kate as my daily editor. One of them is the file browser feature which I find more complicated than its alternatives in Sublime Text or VSCode for example. In addition, the small number of plugins for Kate is also one of the reasons I do not use it.
Kate is the only even remotely close alternative to Notepad++ for me. Close enough that I maintain a personal fork stripping out all the stuff I don't use and modifying a few small things to my preferences (e.g. load/save sessions from file menu, no need for 'session manager'.
If you like Kate you should check out kdevelop. It uses Kate as a core and expands on it.
Much more project management tools and more advanced IDE-isms. It's primarily for C++ but, of course, has all the LSP support of Kate.
You can follow definitions, visually set breakpoints, automatically lint your code, etc. But one of my favorite rare features is the Class Browser. Being able to visually see a class hierarchy is very valuable, particularly for GUI libs and stuff of that nature that really leans into inheritance.
I’m using Kate to write posts on https://oilshell.org! After a detour through many other tools, it’s great to find something open source and high quality.
I use vim to edit code, but I like copying and pasting paragraphs of prose with a mouse. I didn’t realize that until doing a lot of writing.
After Kate was ported to Qt4, I was very impressed that it could handle extremely large files with no sweat. I don't use it, because I need a remote development capabilities and when compared to Neovim it simply lacks the plugin ecosystem and a large community driving it forward.
I use kate a lot when I need to inspect a huge file. Love the built-in rainbow rendering of columns for a CSV. Definitely a solid editor considering it is free and open source. I haven't done any serious dev with it though.
For me this feels similar to why I use Helix[1]. I used to use VSCodium and had tried to switch to Vim or Neovim multiple times but didn't manage because of all the plugin configuration to be able to program. Then I saw an HN post about Helix, started it up and it just worked and so haven't used anything else since.
I find the Helix keybindings easier to learn because you see what text will be affected by any operation before you do it. And by using Helix I've found I've been able to pick up Vim keybindings as well so can use it on a server.
I think it would help if it didn't have such a jarring default colour scheme though.
A plugin system is much less of an issue when Helix has built-in functionality for most of what comes as plugins in Vim. That said integration with git or with code assistants/chat is something that is probably better done via plugins hence it is still on the roadmap.
But in my experience of ~10 months of Helix vs +20 years of Vim, the former is a much more pleasant and hassle-free experience, mostly because of it offering autocompletion, matching, fuzzy file picker, multiple cursors, LSP and go to definition, and other features with no or minimal configuration and the guarantee of stability and support (something that can not always be said when picking among the competing Vim plugins for same)
In fairness Helix provides a lot of functionality out of the box and features are gradually being added all the time. The lack of plugin system is not a problem for many people, and I’d rather they take their time and get it right. I certainly don’t think it’s the case that they’re “trying” and failing to implement plugins - it’s clearly going to happen when the time is right.
And, oddly, they chose to do their own Scheme implementation for it. Not that I'm against Scheme in particular, but a lot of other people justifiably seem to be. It doesn't have the speed or learn-it-in-10-minutes of Lua (nvim) or the historical excuse of Elisp/Vimscript (emacs/vim) or the ecosystem of Typescript (vscode). Strange choice.
I also heard about Helix and have been curious about it, for the same reason. If I’m going to learn Vim keybindings, it’s because I want to move fast. Tweaking configuration files for an evening is the exact opposite of moving fast.
The idea that you constantly need to tweak your config files in vim/neovim is a bizarre myth that seems to have sprung up because vim is so flexible that some people love messing about with config. You can just copy something like vim-sensible to give sensible defaults and get going - you absolutely don't have to do a bunch of tinkering. I have used vim and then neovim for 24 years now and most of my config customization I did more than 15 years ago when I decided to add a bunch of extra keybindings.
I very occasionally will add a plugin or tweak something (eg if I want a new snippet or something) but it's really not necessary to have a big complex config and I would say I spend well under 5 minutes per year on config.
I really wanted to like helix but there are a few really fundamental things that are really crucial to most of my workflows that were just missing (eg reflow text) when I tried it.
Just use https://astronvim.com/. I haven't touched my config for more than a month. With astronvim community, other people do the hard work.
I also tried the "pure" config from scratch way but its just way too much work to maintain, esp if you want all the goodies. Also, not an expert in Lua so my config sucked. Simply better to use an existing, well-maintained neovim distro. I tried all of them and liked astronvim the best.
I’ve also recently switched (largely) from Vim to Zed and I also think that Zed is in many ways great.
At the same time it’s been pretty frustrating to use an editor that is spending so much time building AI integrations, REPLs, and so fourth when basic things like cut and paste and common Vim motions still have so many bugs.
I’d love to see them prioritize getting the basics solid first.
Yeah I feel the same way. The fact that Zed uses the system clipboard as the default register in vim mode, for instance, made it impossible to use in practice for me -- having every yank replace my clipboard was a bit of a nightmare!
I don’t know. That feels perfectly reasonable for what I imagine is 99% of all developers, so while sad, I can imagine why that use case is not very high on their list of priorities.
To be frank I don’t the majority of us care about these collaboration features. We just want a way to write code that is performant but makes it easy to leverage existing language servers.
I want to pay for Zed for what it is. I want to sponsor a new code editor. I have zero interest in paying for a SaaS collaborative editor.
I’m actually in the opposite camp, I had left VSCode for Zed about 6 months ago and used it exclusively at work/personal projects. I’ve customized it extensively, and loved its approach to Vim integration. But in the last two weeks I’ve made the switch to Neovim (using a customized LazyVim [0] setup). I really like Zed but as others have pointed out they are not prioritizing features around REPL’s, AI, and collaboration while many core features are lacking. Vim Cut/Copy and paste being bugged, and html tags not closing drove me crazy over time.
I think Zed is wonderful, and would perhaps go back to it after it matures a bit. For what’s its worth the friction going from Zed -> Neo vim was quite seamless, and I’d expect going the other way would as well.
A couple years ago I got really tired of maintaining my own vim configs, like the author of this piece mentions (plugins and updates causing problems). I just wanted to get out of the business of maintaining my own configs, so I decided to try a bundle, and eventually ended up on LunarVim, with a small handful of "dealbreaker" config changes. As opposed to a basic vim and then a bunch of plugins and custom configs.
I've been pretty happy with it, but other options are worth checking out (SpaceVim, NvChad, LazyVim, AstroVim).
LunarVim has finally deivered a working LSP/TreeSitter which I always only got half working or would break once I had it working, in my self-managed configs.
I had tried and failed multiple times to start using Vim (after using Vim binds for a while), and actually failed the transition right before my 6 month stint with Zed. It was actually this post[0] from the creator of Gleam [1] that brought LazyVim to my attention. I made a handle full of modifications, removing certain plugins and adding others. I'm very happy with the result. Its been two weeks of using it at both work and home productively.
I kinda had the same journey as the author except that I clinged to the terminal workflow he had leave behind. Choosing a Neovim distro was the solution for me.
> Every now and then I would update a plugin in Neovim and everything would break, and I would have to spend time fixing it instead of getting work done.
This is true, but only if you're not using one of the ready made distributions. I didn't switch to NeoVim until I discovered LazyVim and this amazing guide https://lazyvim-ambitious-devs.phillips.codes/.
That changed everything. I just use LazyVim out of the box, as if it was a Jetbrains IDE. No config hassle, no issues with updates. It just works.
Regarding Zed:
It's a small niche they're trying to fill in a very competitive market. Currently they have the advantages of being the current cool thing. But that's not enough in the long run. If I would knew some killer feature, I'd go ahead and write it here. But that's the thing, I can't think of any. For simple, mainstream usage, VS Code is there. Ulimate IDE features: JetBrains IDEs. Ultimate productivity: LazyVim (or other NeoVim setups), ootb modal editing: Helix.
I got fed up of tweaking my own config and keeping up with the very fast moving plugin ecosystem. Gave LazyVim a try (after using LunarVim for a bit) and it's been a breeze. It's very well polished and maintained by a prominent plugin author.
Echoing similar sentiments that I'm optimistic for Zed to become more polished and stable.
Till then, Sublime Text 4 is still the best non-terminal text editor I've ever used and I continue to daily drive it. Sure its paid and non-FOSS, but its incredibly performant on Linux and Windows and its LSP extension + Sublime Merge fill the gap left by VSCode for me. Well worth the price tag IMO.
My only gripe with Sublime Text is that they've changed to a "semi subscription" license model, where licenses expire after 2-3 years, and you essentially need to buy it again after that time.
It's essentially the same model used by other editors like the Jetbrains suite, but unlike Jetbrains, updates to Sublime Text (and Merge) are few and usually don't contain much other than bugfixes.
I've faithfully purchased Sublime Text licenses since the initial versions (switched over from Textmate), but as my ST4 license recently expired, it has forced me to review just what i get for the money i pay.
ST was excellent when it first arrived, and it's still one of the fastest loading editors out there, but pretty much every other editor has more or less caught up, including free ones like Zed and VSCode, making a recurring cost harder to justify.
I'm actually using an expired ST4 license, but as another user already mentioned, you can continue using the versions available to you while your license was active. This is fine for me because I find Sublime Text to be a better experience than VSCode and Zed.
I'm in the same situation. The upgrade price for Sublime Text and Sublime Merge is $152 whereas the full license is $168. As you say, it feels more like a subscription model. I'd renew if the discount was bigger. I can of course continue to use the versions released while my license was valid, but it would be nice to get bug fixes and new feature while still supporting the developers.
I love ST4 but I need to do a lot of remote editing - that is, editing a project on a Linux server. VSC is the only tool I’ve used where the remote edit “works” and it also seems to constantly have problems. I’ve tried things like rmate or SSHFS but they don’t work well. Do you have any advice on a ST4 solution for this? Thanks in advance!
Readit News
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.
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.
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.
This is a ridiculous statement. Citation needed.
¹: https://downloads.regulations.gov/ONCD-2023-0002-0020/attach...
- 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.
It's debatable how accurate it is, but I think the ultimate productivity of developers is actually surprisingly lower than you would think.
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 think the commenter suggests that you can just write those right away and the 100s of lines along the way don't exist
> 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?
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 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.
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.
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.
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.
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.
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.
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
> 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.
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'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.
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.
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.
But as their focus has shifted to building Collaboration & AI features, and still haven’t yet nailed just being a good/great base editor, its become less useful to me.
I still have a lot of hope for Zed.
But for the time being, I’ve switched back to my old editor & IDE … and I’ll try Zed again at a much later date.
Thank god we still have vim and Emacs.
Emacs has had AI since before it was cool again.
M-x doctor
[1] Eight Megabytes and Constantly Swapping
Think of vim/nvim setup as a one time process: a bit complicated, but once done then you are ready to go. Of course, I use text editors for... code editing. No need to turn it into an IDE or mail client or whatever.
Really my own issue with Zed is the crummy TS language server integration. Everything else is fantastic.
I would like some form of built in diffing, but for simple conflicts this is fine.
It's not a deal-breaker, but it is really annoying - I have to find the problem myself with no assistance from the language server. In fact, with hindrance from the language server because it's littering the code with completely spurious warnings of irrelevant "errors" that aren't.
I haven't tried coding in TS on Zed, so I can't comment on how the actual TS experience is.
Collaboration, AI, chat, couldn't care less. Hopefully they can be disabled. I used Atom for a few years before they discontinued it. Yes, it was quite sluggish but otherwise it was usable, it had multiline editing and other sublime-isms, so I didn't have learn how to use an entirely new editor. If Zed can replace Sublime, Atom or VSCode for me that's great, otherwise I'll pass. I'm only using the basic code editor features, no git, no collaboration, no integrated terminal, no nonsense. Multiple cursors, PCRE matching and dark theme (preferably molokay) are a must.
I tried Zed for one day, without collaboration or AI enabled. It has some un-rounded edges, for example, the scroll bar in some window frame don't even work, but I can still get some job done with it. I use VS Code daily, Zed reminded me how a faster and snappy interface should make me feel. I hope Zed succeed.
They are now trying to do collaboration with ai to return money to investors but again nobody wants this.
That's why most editing tools should be open source and done by people passionate about it. The only company that managed to do paid editoes well is Jetbrains because their IDEs are actually much much better than the competition and much better than Zed.
I love the AI integration in Zed, it’s really smooth, pleasant to use, and well-integrated. I have a good experience pairing it with Sonnet 3.5.
The REPL feature is great as well and I totally see myself using that.
I agree on the collaboration bit though. I understand it’s one of the original premises and goals of Zed, however in order for it to really work well, I think you’d need to get everybody in your company to use Zed… which is honestly a “pretty tough” sell. I could imagine it making more sense if they had IntelliJ and VSCode plugins integrated with it, so the adoption could be more incremental.
That said, I agree that I definitely miss e.g. debugging support.
[1] https://kate-editor.org/
[2] I must say here too that Nano is actually an underappreciated gem. It supports a lot more features than people generally imagine: syntax hilighting, line numbering, auto-indent, multi buffers, mouse support, keyboard macros, … it's actually a decent simple code editor!
[3] https://kate-editor.org/post/2022/2022-08-24-kate-new-featur...
Much more project management tools and more advanced IDE-isms. It's primarily for C++ but, of course, has all the LSP support of Kate.
You can follow definitions, visually set breakpoints, automatically lint your code, etc. But one of my favorite rare features is the Class Browser. Being able to visually see a class hierarchy is very valuable, particularly for GUI libs and stuff of that nature that really leans into inheritance.
I use it for mainly writing small Go programs in these days. Bigger projects are promoted to Eclipse.
I use vim to edit code, but I like copying and pasting paragraphs of prose with a mouse. I didn’t realize that until doing a lot of writing.
I've replaced unsaved files in Kate with obsidian.md personally, as there if there is somewhere I can type, I know it will be persisted to disk.
I find the Helix keybindings easier to learn because you see what text will be affected by any operation before you do it. And by using Helix I've found I've been able to pick up Vim keybindings as well so can use it on a server.
I think it would help if it didn't have such a jarring default colour scheme though.
[1] https://helix-editor.com/
But in my experience of ~10 months of Helix vs +20 years of Vim, the former is a much more pleasant and hassle-free experience, mostly because of it offering autocompletion, matching, fuzzy file picker, multiple cursors, LSP and go to definition, and other features with no or minimal configuration and the guarantee of stability and support (something that can not always be said when picking among the competing Vim plugins for same)
I love Helix and used it a bit, but the lack of plugins (and thereby features) made me switch.
I very occasionally will add a plugin or tweak something (eg if I want a new snippet or something) but it's really not necessary to have a big complex config and I would say I spend well under 5 minutes per year on config.
I really wanted to like helix but there are a few really fundamental things that are really crucial to most of my workflows that were just missing (eg reflow text) when I tried it.
I also tried the "pure" config from scratch way but its just way too much work to maintain, esp if you want all the goodies. Also, not an expert in Lua so my config sucked. Simply better to use an existing, well-maintained neovim distro. I tried all of them and liked astronvim the best.
At the same time it’s been pretty frustrating to use an editor that is spending so much time building AI integrations, REPLs, and so fourth when basic things like cut and paste and common Vim motions still have so many bugs.
I’d love to see them prioritize getting the basics solid first.
Deleted Comment
I want to pay for Zed for what it is. I want to sponsor a new code editor. I have zero interest in paying for a SaaS collaborative editor.
I think Zed is wonderful, and would perhaps go back to it after it matures a bit. For what’s its worth the friction going from Zed -> Neo vim was quite seamless, and I’d expect going the other way would as well.
0: http://www.lazyvim.org/
I've been pretty happy with it, but other options are worth checking out (SpaceVim, NvChad, LazyVim, AstroVim).
LunarVim has finally deivered a working LSP/TreeSitter which I always only got half working or would break once I had it working, in my self-managed configs.
0: https://lpil.uk/blog/what-i-use-2023/#software
1: https://gleam.run/
I kinda had the same journey as the author except that I clinged to the terminal workflow he had leave behind. Choosing a Neovim distro was the solution for me.
This is true, but only if you're not using one of the ready made distributions. I didn't switch to NeoVim until I discovered LazyVim and this amazing guide https://lazyvim-ambitious-devs.phillips.codes/.
That changed everything. I just use LazyVim out of the box, as if it was a Jetbrains IDE. No config hassle, no issues with updates. It just works.
Regarding Zed:
It's a small niche they're trying to fill in a very competitive market. Currently they have the advantages of being the current cool thing. But that's not enough in the long run. If I would knew some killer feature, I'd go ahead and write it here. But that's the thing, I can't think of any. For simple, mainstream usage, VS Code is there. Ulimate IDE features: JetBrains IDEs. Ultimate productivity: LazyVim (or other NeoVim setups), ootb modal editing: Helix.
I got fed up of tweaking my own config and keeping up with the very fast moving plugin ecosystem. Gave LazyVim a try (after using LunarVim for a bit) and it's been a breeze. It's very well polished and maintained by a prominent plugin author.
Speed to open and general snappiness. Nothing comes close to Zed especially in larger codebases as most agree in the thread.
Dead Comment
Till then, Sublime Text 4 is still the best non-terminal text editor I've ever used and I continue to daily drive it. Sure its paid and non-FOSS, but its incredibly performant on Linux and Windows and its LSP extension + Sublime Merge fill the gap left by VSCode for me. Well worth the price tag IMO.
It's essentially the same model used by other editors like the Jetbrains suite, but unlike Jetbrains, updates to Sublime Text (and Merge) are few and usually don't contain much other than bugfixes.
I've faithfully purchased Sublime Text licenses since the initial versions (switched over from Textmate), but as my ST4 license recently expired, it has forced me to review just what i get for the money i pay.
ST was excellent when it first arrived, and it's still one of the fastest loading editors out there, but pretty much every other editor has more or less caught up, including free ones like Zed and VSCode, making a recurring cost harder to justify.