I thought this was going to be pretty bland from the story title on main page, clicked into the comments and saw your series title then watched the video. Absolutely great series, and a good collection of people you’ve interviewed so far. My initial reaction was definitely wrong and I’m glad I clicked in to the comments here. Good work!
Thanks for the video / interview! It’s a refreshing and apparently non-mainstream take, especially now in 2023 when Emacs almost seems reasonable in comparison with VS-Code and others… :)
It completely and exactly describes my own development workflow:
tiling window-manager (i3 in my case) with a terminal multiplexer (tmux);
simple text editor (no IDE-features, not even auto-completion, syntax-highlighting and other niceties) – my own sce in my case; (complemented with mc to browse between the files;)
another shell for testing; actually multiple shells for all kind of tasks;
script everything for easy use – with my own z-run; (although make or just would do just fine;)
and obviously Firefox for reading the documentation;
In essence: keep close to CLI and TUI tools!
Another interesting (and unpopular take) is reading the actual reference manual / documentation instead of randomly copy-pasting stuff from stack-overflow until something barely works!
Indeed — I really enjoyed hearing how he reads the manual, which is the opposite of what Julia Evans said she does in this other episode. Interesting to see two programmers I respect a lot taking very different approaches to the same problem.
I wrote a hack (a system init) for THINK C in the 90s called THINK Power that would add a little function pop-up to the window title bar. It allowed you to quickly navigate through the file. It probably lives somewhere in an old Info-Mac archive.
IMHO, IDE’s and complex editor configurations have two or three major problems:
more failure modes, some of which might not be immediately obvious or understandable
if you ever change your environment/work on multiple machines, you’re likely not going to be able to take your environment with you
if you SSH into remote machines, a graphical IDE might not work very well (though from what I understand it’s getting better lately)
And one minor problem:
occasionally I will need to do something that the IDE doesn’t do, so I’ll need to drop to the shell…if I have to do that more than a few times, I might as well just treat the shell as my IDE since it can do everything I need
Indeed! It didn’t make the final edit, but Mitchell spoke about these cases as well. He needed to do a lot of editing while sshed into remote machines, so being productive in minimally configured vim has been an advantage.
On the one hand, my happy feelings about VS Code are unchanged by this anecdote, which, by the way, does not come across at all like a concession to a “worst” practice but more like a promotion of asceticism. I have tried this editor-hewn-from-rock-that-will-outlive-your-grandchildren thing a couple of times. Noble, I’m sure, but not for me. VS Code brought us LSP, the ubiquitousness of which has already saved me countless hours. Why rely on old docs or an outdated reference manual when you can see type definitions, implementations, and references in the actual source code in an instant?
On the other hand, when people cultishly chain a project to a particular editor or IDE, it makes me want to run in the other direction. So when I hear this story, I also think, “Vive la différence,” and am reminded of the reason I leave the door open for anyone who inherits one of my projects to be able to do all the essential tasks with any text editor and a command line. Whether they chose to benefit from LSP or not is up to them. It does not, after all, leave claw marks in a codebase the way IDEs typically do.
My dislike of traditional IDEs dates back to my college years. They were slow and crashed often. Their UIs felt as cluttered as a house of a packrat. So I wrote almost everything in BBEdit, including Java, which was probably as painful to write there as in the IDE I was avoiding. I continued using simple text editors after college and I got pretty good at spotting my syntax and type errors before compilers and interpreters did. But I do not consider this an enduringly relevant skill. Thanks to LSP, one does not need to drink some IDE’s kool-aid to get IDE-like benefits anymore.
Yes! At my current work people look at me like I went senile or something when they somehow learn I use simplest tools for all the programming - nano and shell.
I moved to that approach several years ago and honestly can’t say it hindered much of a speed or anything; at some point I think it is not about how much code you can churn out as fast as possible but mostly to figure out what needs to be done at all.
Back in the days I started my coding in Turbo Pascal, it was a good IDE: small, to-the-point, helpful. Then I moved on to Delphi, it was good as well. Then I started learning “a real language”, C++. Visual Studio, DevCpp, even Borland whatever plus plus, they all were endless pits of frustration for a hyperactive inattentive brain. I had learned to hate Visual Studio and IDEs in general with passion.
I moved on to Linux, learned vim, spent a few years coding C, Haskell, Python and shell in it. The focus they brought was enjoyable. I learned to use ctags. I dabbled with YouCompleteMe and other plugins. I tried every opensource IDE available at that point (KDevelop, Anjuta, CodeBlocks, Eclipse/EDT), I did not see any value in using any of that. QtCreator was okay, but Qt-oriented. I did not get Java and how IDE-oriented it was.
Then the wave of modern languages happened: Scala, Rust, Go. IntelliJ finally started make some sense. C++ started to settle on the least common denominator, CMake. Language servers started to pop up. Nowadays I recognize how much I missed, how much friction the tmux-vim-browser workflow and context-switching added. As long as IDEs do not get in the way, they shave off iteration time quite well. Today I’m happy with VSCode + rust-analyzer, it’s just the best of both worlds: vim emulation, documentation, semantic highlighting (e.g. for Rust: underlining mutable variables/operations, marking move sites with red, references with blue, etc), diagnostics, “Run test”, terminal emulator at my fingertips. Going back to bare vim feels like a chore, highlighting with regexps feels mostly dumb and unnecessary now.
Conclusion? Do not get stuck on one True Way: try writing something in a barebones editor, try customizing vim/emacs to your liking, try a rich IDE, try different workflows. No size fits all. Things change.
Count me in as another Vim and plain shell / terminal user :) (although I also use tmux)
Vim’s Ctrl-N seems to be enough for 95% of autocomplete, and I use gF to jump to MyPy errors and grep -n output.
One thing I’m missing is a good (fast and open source) environment for making plots and diagrams though (e.g. graphviz or SVG). The terminal is OK but it would be nice to iterate faster inline. I wonder if Emacs is good for that
Also it’s very hard to imagine learning to program with 2 hours a week of computer time as a child – that’s very impressive / unusual!
edit: one thing I would like to do is somehow replicate my tmux + vim workflow into emacs (for org-mode/org-roam). I’ve tried it once almost every year and I just can’t make it work the way I want.
It’s great to hear that there’s at least one other person with a similar “no frills” workflow, judging by the other comments there are at least a few of us. I’m the same: vim (no plugins, no syntax highlighting) + tmux + reading docs and reference manuals.
This video was quite timely. Last weekend I finally decided to take a fresh look at my workflow and installed a number of plugins to give me some LSP/ autocomplete goodness. I found it so distracting but decided to power through. Over the last week I’ve gradually ended up turning off feature by feature until this morning (7 days after my experiment started) I’m back where I started with no plugins. Feels much less distracting
I still think I write my best code this way, but it only works for small code bases I know extremely well. I prefer a full-featured text editor when I need to browse a large shared codebase.
I use Emacs, but without many frills. I think having “intelligent” indentation is the only language-sensitive feature that I really depend on, as it catches many syntax errors immediately.
I use kwrite + yakuake. No autocomplete, minimal frills, just syntax highlighting.
To build, I have F12-arrowup-return (focus yakuake, last command, execute) permanently baked into my fingers.
Watching my colleagues, man, grep, less etc. are either competitive or faster than the various IDE built-in project search features.
I also use this bit of bashrc magic to make Ctrl-E autocomplete to “edit $file”, where $file is selected by fzf. Thanks to the incremental search, I can open a file that I know the name of in less than a second.
I’ve tried various IDEs over the past 30 years, and in every case, it either refused to work with my existing code, or outright crashed. Also, I can use any language with a text editor, the same can’t be said for IDEs.
It has been my experience. I don’t try often (maybe every five to ten years). The last time I tried (and this was a few years ago), I attempted to load up a simple C project into an IDE [1] and it immediately crashed. Now, said IDE claimed it supported C and C++, but I suspect it really meant C++, because the C file I tried loading used class as a structure field name (which is fine for C). If an IDE can’t deal with C code as it is I can’t use it.
Then there was the Java IDE I tried years ago. It couldn’t deal with my code as apparently the creators of said IDE never considered that anyone would attempt to write their own Java layout manager (for the “native” Java UI at the time) and refused to even work with the project.
[1] I’ve forgotten which one, and frankly, I don’t care.
I was asking myself: Which software engineer would write serious amounts of code SSH’ed into other machines…?
Then I remembered Hashimoto works on a Mac but has a Nix/VM heavy workflow. He comments explicitly that he almost never runs GUIs in those terminals because the performance is not good enough.
That means he’s probably better off writing the code straight in the Linux VM because cross-compiling from macOS into Docker/Linux to me at this point is more or less entirely theoretical. Also why go through the hassle of mapping your local folder into the VM just to be able to use VSCode if everything else is happening in the VM anyway.
Another installment of my new YouTube channel, “Worst Practices in Software Development”. Would love to hear your feedback. Thanks for watching!
Great series, and jealous you get to talk with such amazing people.
I thought this was going to be pretty bland from the story title on main page, clicked into the comments and saw your series title then watched the video. Absolutely great series, and a good collection of people you’ve interviewed so far. My initial reaction was definitely wrong and I’m glad I clicked in to the comments here. Good work!
Thanks for the video / interview! It’s a refreshing and apparently non-mainstream take, especially now in 2023 when Emacs almost seems reasonable in comparison with VS-Code and others… :)
It completely and exactly describes my own development workflow:
i3in my case) with a terminal multiplexer (tmux);mcto browse between the files;)makeor just would do just fine;)In essence: keep close to CLI and TUI tools!
Another interesting (and unpopular take) is reading the actual reference manual / documentation instead of randomly copy-pasting stuff from stack-overflow until something barely works!
Indeed — I really enjoyed hearing how he reads the manual, which is the opposite of what Julia Evans said she does in this other episode. Interesting to see two programmers I respect a lot taking very different approaches to the same problem.
I’ve got too much going on in my life not to have autocomplete in my daily driver code editor.
Cries in THINK C 5 editor
I wrote a hack (a system init) for THINK C in the 90s called THINK Power that would add a little function pop-up to the window title bar. It allowed you to quickly navigate through the file. It probably lives somewhere in an old Info-Mac archive.
IMHO, IDE’s and complex editor configurations have two or three major problems:
And one minor problem:
In other words, “UNIX is my IDE”
Ok, lets go :
Then lets’ all switch back to DOS instead of Linux/Windows because clearly simpler software is better, right ?
Visual Studio, for example, has a way to sync your settings to a new environment/machine.
Agree with this one, just don’t SSH for development, running things locally is so much better/faster.
Indeed! It didn’t make the final edit, but Mitchell spoke about these cases as well. He needed to do a lot of editing while sshed into remote machines, so being productive in minimally configured vim has been an advantage.
My unwillingness to work with high-latency low-fidelity editors over SSH makes me fight for portable software that is runnable locally.
I’ve moved some projects from “to run this, start a k8s cluster” to “to run this, run
cargo run”.I largely agree with you, but VSCode does solve 2 and 3 fairly nicely via settings sync and remote editing, respectively.
lol it’s me. Glad I’m not the only one
On the one hand, my happy feelings about VS Code are unchanged by this anecdote, which, by the way, does not come across at all like a concession to a “worst” practice but more like a promotion of asceticism. I have tried this editor-hewn-from-rock-that-will-outlive-your-grandchildren thing a couple of times. Noble, I’m sure, but not for me. VS Code brought us LSP, the ubiquitousness of which has already saved me countless hours. Why rely on old docs or an outdated reference manual when you can see type definitions, implementations, and references in the actual source code in an instant?
On the other hand, when people cultishly chain a project to a particular editor or IDE, it makes me want to run in the other direction. So when I hear this story, I also think, “Vive la différence,” and am reminded of the reason I leave the door open for anyone who inherits one of my projects to be able to do all the essential tasks with any text editor and a command line. Whether they chose to benefit from LSP or not is up to them. It does not, after all, leave claw marks in a codebase the way IDEs typically do.
My dislike of traditional IDEs dates back to my college years. They were slow and crashed often. Their UIs felt as cluttered as a house of a packrat. So I wrote almost everything in BBEdit, including Java, which was probably as painful to write there as in the IDE I was avoiding. I continued using simple text editors after college and I got pretty good at spotting my syntax and type errors before compilers and interpreters did. But I do not consider this an enduringly relevant skill. Thanks to LSP, one does not need to drink some IDE’s kool-aid to get IDE-like benefits anymore.
Yes! At my current work people look at me like I went senile or something when they somehow learn I use simplest tools for all the programming - nano and shell.
I moved to that approach several years ago and honestly can’t say it hindered much of a speed or anything; at some point I think it is not about how much code you can churn out as fast as possible but mostly to figure out what needs to be done at all.
Back in the days I started my coding in Turbo Pascal, it was a good IDE: small, to-the-point, helpful. Then I moved on to Delphi, it was good as well. Then I started learning “a real language”, C++. Visual Studio, DevCpp, even Borland whatever plus plus, they all were endless pits of frustration for a hyperactive inattentive brain. I had learned to hate Visual Studio and IDEs in general with passion.
I moved on to Linux, learned vim, spent a few years coding C, Haskell, Python and shell in it. The focus they brought was enjoyable. I learned to use ctags. I dabbled with YouCompleteMe and other plugins. I tried every opensource IDE available at that point (KDevelop, Anjuta, CodeBlocks, Eclipse/EDT), I did not see any value in using any of that. QtCreator was okay, but Qt-oriented. I did not get Java and how IDE-oriented it was.
Then the wave of modern languages happened: Scala, Rust, Go. IntelliJ finally started make some sense. C++ started to settle on the least common denominator, CMake. Language servers started to pop up. Nowadays I recognize how much I missed, how much friction the tmux-vim-browser workflow and context-switching added. As long as IDEs do not get in the way, they shave off iteration time quite well. Today I’m happy with VSCode + rust-analyzer, it’s just the best of both worlds: vim emulation, documentation, semantic highlighting (e.g. for Rust: underlining mutable variables/operations, marking move sites with red, references with blue, etc), diagnostics, “Run test”, terminal emulator at my fingertips. Going back to bare vim feels like a chore, highlighting with regexps feels mostly dumb and unnecessary now.
Conclusion? Do not get stuck on one True Way: try writing something in a barebones editor, try customizing vim/emacs to your liking, try a rich IDE, try different workflows. No size fits all. Things change.
I can’t imagine not having go-to-definition
grep \ fooFun\( src -R:)With more text-mode editors (such as helix-editor.com) adopting the Language Server Protocol, its great to have go-to-definition in humble vim-alikes.
I’m mostly the same - keeping it to vim… but I use vim’s built-in completions for filenames & other variables in the current document.
Count me in as another Vim and plain shell / terminal user :) (although I also use tmux)
Vim’s Ctrl-N seems to be enough for 95% of autocomplete, and I use
gFto jump to MyPy errors andgrep -noutput.One thing I’m missing is a good (fast and open source) environment for making plots and diagrams though (e.g. graphviz or SVG). The terminal is OK but it would be nice to iterate faster inline. I wonder if Emacs is good for that
Also it’s very hard to imagine learning to program with 2 hours a week of computer time as a child – that’s very impressive / unusual!
So what you’re telling me is…vim with no customization other than format-on-save is a trauma response.
he works almost exactly like I do, lol
edit: one thing I would like to do is somehow replicate my tmux + vim workflow into emacs (for org-mode/org-roam). I’ve tried it once almost every year and I just can’t make it work the way I want.
It’s great to hear that there’s at least one other person with a similar “no frills” workflow, judging by the other comments there are at least a few of us. I’m the same: vim (no plugins, no syntax highlighting) + tmux + reading docs and reference manuals.
This video was quite timely. Last weekend I finally decided to take a fresh look at my workflow and installed a number of plugins to give me some LSP/ autocomplete goodness. I found it so distracting but decided to power through. Over the last week I’ve gradually ended up turning off feature by feature until this morning (7 days after my experiment started) I’m back where I started with no plugins. Feels much less distracting
That’s a bad practice I have had as well, for a very long time. I mostly use it on my own projects nowadays though, or on very specific code bases at work.
I still think I write my best code this way, but it only works for small code bases I know extremely well. I prefer a full-featured text editor when I need to browse a large shared codebase.
I use Emacs, but without many frills. I think having “intelligent” indentation is the only language-sensitive feature that I really depend on, as it catches many syntax errors immediately.
I use kwrite + yakuake. No autocomplete, minimal frills, just syntax highlighting.
To build, I have F12-arrowup-return (focus yakuake, last command, execute) permanently baked into my fingers.
Watching my colleagues,
man,grep,lessetc. are either competitive or faster than the various IDE built-in project search features.I also use this bit of bashrc magic to make Ctrl-E autocomplete to “edit $file”, where $file is selected by fzf. Thanks to the incremental search, I can open a file that I know the name of in less than a second.
You earned yourself a new subscriber! Love this kind of content.
Thank you!
I’ve tried various IDEs over the past 30 years, and in every case, it either refused to work with my existing code, or outright crashed. Also, I can use any language with a text editor, the same can’t be said for IDEs.
What? This just doesn’t sound true.
It has been my experience. I don’t try often (maybe every five to ten years). The last time I tried (and this was a few years ago), I attempted to load up a simple C project into an IDE [1] and it immediately crashed. Now, said IDE claimed it supported C and C++, but I suspect it really meant C++, because the C file I tried loading used
classas a structure field name (which is fine for C). If an IDE can’t deal with C code as it is I can’t use it.Then there was the Java IDE I tried years ago. It couldn’t deal with my code as apparently the creators of said IDE never considered that anyone would attempt to write their own Java layout manager (for the “native” Java UI at the time) and refused to even work with the project.
[1] I’ve forgotten which one, and frankly, I don’t care.
I was asking myself: Which software engineer would write serious amounts of code SSH’ed into other machines…?
Then I remembered Hashimoto works on a Mac but has a Nix/VM heavy workflow. He comments explicitly that he almost never runs GUIs in those terminals because the performance is not good enough.
That means he’s probably better off writing the code straight in the Linux VM because cross-compiling from macOS into Docker/Linux to me at this point is more or less entirely theoretical. Also why go through the hassle of mapping your local folder into the VM just to be able to use VSCode if everything else is happening in the VM anyway.