Screenshots from developers: 2002 vs. 2015 (2015)

common theme: tiled layout, terminals, minimum fancy decorations.

I think I see only one truly tiled layout. But yes, "terminals and editors" as the core developer workflow is extremely conserved over time. It dates from the mid 80's on Sun 2's and really hasn't changed much in four decades.

It's probably not worth arguing whether this is the "best" when compared with vscode+LSP+Claude or whatever happens to be en vogue in the moment.

But terminals and editors is sticky in a way that tells me it's probably close to optimal. Those of us in the cult aren't observed to leave the compound except in extremely rare circumstances. I'll be doing the same stuff on my death bed, likely.

And that hasn't changed much since. At work and at home, I'm usually looking at emacs with no tab or menu bar, full screen on all monitors, with everything else (browser, etc) a virtual desktop switch away: exwm at home, one terminal emacsclient in ssh per monitor with a single daemon on linux server (accessed from Windows) at work. With many minor variations this is how my desktop has looked since my first programming job, which coincidentally was in 2002, but the details of the setup have changed a lot. The bit that has remained constant is that all I want on my monitor(s) when I'm programming is code.

Edit: Probably the most visible change is better fonts and font rendering.

Edit 2: To expand on "all I want is code": let's say there is a menu bar with maybe 10 menus and 100 or so items, and a project navigator thingy, and a compiler output window. I would much rather these things not take up permanent space on my screen. Every one of them shows information/commands that I can access with a key combination and in some cases some fuzzy completion after hitting a key combination. Any decent editor can do this and you can learn it in an afternoon, and if you're going to spend the next couple of decades in front of it it's worth getting rid of the pixels permanently allocated to advertising "you can do this thing".

> But terminals and editors is sticky in a way that tells me it's probably close to optimal.

Optimal for those users, at any rate. IMO using a terminal editor is so painful compared to a decent GUI (Sublime or even VSCode) that I have a difficult time understanding why anyone would choose such a tool. I just try to repeat the mantra of "everyone likes different things" and stop trying to understand something where I likely never will get it.

It’s funny. I thought the same thing before taking the time to become familiar with VIM keybindings and now I find VS Code tedious and painfully slow.

I guess once one gets used to it or anything it’s going to be more productive than the rest of the tools.

Take about anything from a standard GUI editor. In a terminal editor, they are also easily accessible. And more easily accessible (if not discoverable). But one of the major gain is how close your shell is. A lot of editors allows to start a cli tool and optionally send a portion of the current buffer as input to it. You may also be able to include the output in some buffer too. Some GUI editors allows that, but it's almost always a config maze and you're never sure of the environment in which it does run the commands.

Also in a terminal environment, all you enter are keyboard keys. If you know how to touch-type, your cognitive load can be greatly reduced (personal feeling). You can also navigate something like sublime with keyboard only. But it's way more tiresome.

For me its how easy it is to extend. Kakoune makes it so easy to integrate with the rest of my system. I can often create any kind of integration I need with just 1-10 lines of code. In vscode I need to just hope that someone else built the integration I need as a plugin, because writing plugins is really painful.

what's difficult about it?

I have auto complete, LSP, format on save for may languages, fuzzy finding. my neovim config file is 355 lines, with comments and line breaks.

Normal, good editors are great already with 0 line config. That's the whole point.

Terminal editors generally do support the mouse, and there are occasions where even a fairly skilled user of a good terminal editor will find it easier to click to set an insertion point than use commands to reach it. But having those key-command options greatly enhances the experience. You need to watch the screen while a skilled user edits text to get it. It's like magic.

I haven't picked up nearly as much as I'd like, but even basics (requiring zero config) are way beyond what I could easily do in any GUI editor I ever experienced. For example, in vim, if you are on a bracket or parenthesis (open or close) in edit mode, it is three keystrokes to delete the entire bracketed portion, precisely, regardless of size (even if the matching bracket is off screen). Finding the matching bracket with the mouse is often hell.

And it's not as hard to learn as you may expect, because those keystrokes are not magic codes; they're part of a consistent, thoughtfully designed command language. You choose a mode for selecting text (character based, with lowercase v), use "motions" to select the text in that mode (in this case, a single "go to the matching bracket" motion, which is the percent sign), and take an action with that selection (delete it, with d).

I wonder if there's a worthwhile time-saving in aggregate? To me it seems like overall the bottleneck is always thinking what code to write/edit, not the actual edition. So I'm not convinced shaving a couple seconds here and there outweighs the benefit of a modern IDE or offsets the time spent ricing such a setup.

Seems like the opposite to me. IDE fashion changes like the wind. "Normal developers" are constantly starting over with new tools and new paradigms every time they start work on a new project. Gotta have the right vscode extensions to flash your firmware, IT only supports IntelliJ on the new job, ad infinitum. It's been this way for decades.

My .emacs file gets updated regularly, sure, but it's thirty years old, and my basic flow hasn't changed.

> To me it seems like overall the bottleneck is always thinking what code to write/edit

I feel the same way. But small advantages compound to at least some extent (see e.g. https://danluu.com/productivity-velocity/); and I find that noticing that it takes more time than I'd like to write/edit something, risks breaking my flow.

It's not mainly about speed (although the ceiling is much higher), but about ergonomics, and, plainly, enjoyability. The other benefit of making your own environment is mastery and control; only you can decide when and how the environment changes.

I've came across Mitchell Hashimoto (founder and main programmer behind Hashi Corp and now Ghostty) saying that he uses bare VIM and it took him long time to even use auto formatter with it. He also said that the way for him to explore APIs is to read the docs first :)