As a long time terminal user, it does not surprise me much when people just don't get it. The discussion often goes like this:
— In a terminal, I can do so-and-so with a simple command
— Well, in my FrobnicatorStudio, there's a shortcut Ctrl+Alt+So for that
and this can go forever, going into pretty much useless comparisons like "in vim, I can delete 24 lines by pressing four keys" (no Sublime user ever needs that) vs "in Sublime I have multiple cursors" (no vim user ever needs that either).
The proper argument here, probably, is this one: the terminal, with its way of combining small CLI tools
into pipelines, covers infinitely many use cases, but indeed has a learning curve, taking probably a year or so to become really comfortable. When you reach that point, you will be, on average, much more productive than an average GUI user, but it requires some dedication, pain, and suffering to reach that point, and people often do it involuntarily.
In my case, my first job required managing customers' servers over ssh, those servers had bare minimum installed (often vi, not vim), and I had no choice other than figuring out how to do things effectively in this setup. If not for that experience, I'm not sure I would've gone through the pain of starting doing things in the terminal.
I don't think your logic is off, but I also think that the FrobnosticatorStudio people have a point. The thing is, yes, the terminal gives you infinitely more capabilities but you probably have like, 20 actual things you do regularly? The learning curve makes it a hard sell when those 20 things are probably all you need. Like, sometimes I'll do something like this if I'm in a terminal and I want to find a build script
cat packages.json | jq .scripts
And that's useful if I'm in the terminal, but if I'm in VSCode I'll just do
ctrl-p -> packages.json <enter> -> ctrl-f -> scr
It's actually fewer keystrokes.
I dunno, I've learned that people's workflows are really personal so I'd never tell someone to switch their's, but for me I prefer tools that understand the structure of my project instead of just treating it like text, so IDEs are a preference for me.
I agree that both approaches are equally fast, and I myself did use VS Code at work a lot before the agents became widespread, so I can imagine myself doing either options. The terminal version is still less keystrokes because of the tab completion or reverse-i-search, but that's nitpicking.
> people's workflows are really personal so I'd never tell someone to switch their's
I regularly, especially when working with younger colleagues at work, find myself struggling to look at how slow they are in the terminal, like when they hit the up arrow 20 times to find the specific command in the history. If I have a close enough relationship with a person to make sure my advice won't be considered rude, I'd probably say “Ctrl+R and then type”, or even “let me show you how I would do it faster”, but doing this too often is borderline rude, so sometimes I just watch and feel bad for them.
I've seen it with seniors too. The smartest person I worked with (by far!) used to constantly use the menus in Visual Studio (OG Visual Studio, not code) for basically every operation. It was incredibly painful to watch. Watching him debug was a nightmare.
The second smartest guy I worked with couldn't really type properly. (He'd use two fingers). He was still a fantastic coder.
The thing is though, it kind of didn't matter because the value these guys provided was with their incredibly high intelligence, and the friction with how they interacted with tools was more of an issue on the margins than a big deal.
I think for people solving easier problems than these guys (who were working on legitimately hard problems), like, a webdev fixing frontend code, tools might matter a lot because there's less thinking and more navigating and typing. So context matters here a lot. But I definitely don't think you get to be an amazing programmer by CLI mastery (it definitely helps, but it's not a requirement)
I have used and use both regularly. The IDE makes the normal stuff really fast, but the CLI enables things that just can't be done in the IDE. I quite often ended up being the guy that dealt with things quickly, especially in an emergency. I just had the tools to get things done quickly, even when I hadn't been in that situation before. And I say that without even being good at awk and sed, which are used a lot by others in those situations. I always meant to get good at them, but never did. I ended up using other simpler tools instead to get the same kinds of things done.
In short, knowing the CLI way is absolutely useful, even if you use the IDE for 95% of stuff. And I also don't recommend going full CLI, because the IDE way is faster for that 95%.
Most things in life are about balance, and that's true here, too.
My usual thought on this is that I don't want to get stuck at ctrlp ctrlf level. I always pick a tool that gives an intermediate expressiveness level even if it means a bit more efforts.. especially if it's not gui because I can reuse and compose it.
For instance jq falls too far on the capabilities curve. It's a nuclear weapon but it's almost a programming language and I never can keep the operators in mind (even though I loved the idea at first).
It is a programming language. That thing you write between single quotation marks when you invoke jq is a program. (And like with other programming languages, it's often useful to write your jq programs to files instead of always writing them inline in the shell.)
I love jq, though. It provides an extremely good language for its task, even if I often have to take a look at the manual when writing an interesting jq program.
fwiw, Clojure pretty much replaced jq in my toolbelt. Dealing with EDN is so much gratifying - it's almost twice more compact than JSON, it's far more readable; filtering, grouping, sorting, slicing data is so much more straightforward and actually composable, not to mention that I get to do that interactively, directly from my editor.
My shell is configured to show me previews of commands that match from my history. Depending on how long ago I typed the cat command, it might be "cat -> tab -> return"
> I prefer tools that understand the structure of my project instead of just treating it like text
... but in the example you gave, did you not just have it pull up the text contents of a file in a window, and search through it (visually) as text? And on the command line, did you not invoke `jq` specifically to parse the JSON file as JSON?
And really, there is no reason that a TUI pager can't have progressive search that highlights matches. For that matter, vim actually does it. On the other hand, if you're just trying to jump forward to a named unique section, then the appropriate comparison is
> less packages.json <enter> -> /scr
Sure, `less` is more keystrokes than ctrl-p. But you're doing it in a much more general environment (it has to select from every program on your path), so of course it is.
If we make a distinction between CLI apps and TUI apps, my interpretation is that the article was specifically talking about the latter.
By a CLI app (with the emphasis on command line) I mean something like grep, sort, cp, git, ls, tar, etc. The normal way of interacting with these is by writing commands on the shell, which means that if you know how to use it normally, you can also use it in a script. Which means that you can combine these into pipelines.
By a TUI app I mean (and I think the article means) something like Vim, Emacs, Tmux, Lynx, Tig, Midnight Commander, Claude Code, etc. - an interactive app that takes over your terminal while you're using it. You're not going to compose those into a pipeline. Or to be more precise, you're not going to use them in pipeline by using them the way you normally use them. If you can use them, it's probably because the app decided to provide a command-line interface in addition to the TUI.
You should not underestimate how confusing those CLI tools are to people who have never used them before.
For example, I would argue that for someone with no experience, figuring out how to copy a file from one folder to another is easier in Windows Explorer than learning how to use cp.
> For example, I would argue that for someone with no experience, figuring out how to copy a file from one folder to another is easier in Windows Explorer than learning how to use cp.
I don't believe this.
If you find a person (well, two I guess for this experiment) with no computer experience and want to teach them how to copy files, your first step will be teaching them what is a file and how they are organized in the computer.
Explaining what a file is takes the same amount of time for both cases (we can ignore how devices and processes are files in Linux and how files in Windows contain many data streams and extra metadata).
In both cases you need to teach them the file system is hierarchical and folders can be nested and can contain files.
For Windows you have to teach them how to double click to open folders. They can double click "My Downloads" to see their downloads. They can double click "My Music" to see their music files.
For the CLI you have to teach them that `ls` can list the contents of a directory. They can `ls Downloads` to see their downloads. They can `ls Music` to see their music files.
For Windows you then teach them they can open multiple windows (assuming you want to copy from one folder to another folder). And you teach them they can click, hold and drag and drop a file to move it (but sometimes it will be copied when they do that) and they can hold in Control while dropping to copy the file to the destination instead. Or you teach them they can use Ctrl+C to mark a file for being copied and then navigate to the destination and use Ctrl+V to copy the file. Or you teach them to right click for the right click menu, and that "copy" means "mark this file for being copied", and that a right click in the middle of a window displaying the target folder lets them select "paste" which means "copy the marked file here".
For the CLI you teach them `cp Downloads/foo.mp3 Music/` copies foo.mp3 from their downloads to their music directory.
The CLI is also infinitely easier to help newbies use over the phone!
Look I’m a big fan of having CLI interfaces, and they can definitely let you do things that you just can’t do (or are extremely difficult to do) with a standard desktop gui. But at the same time, the GUI means they never have to learn that `cp Downloads/foo.mp3 Music /` will give them a cryptic error that Music can’t be found. Or that if they’re already in the Downloads directory then they need to instead type `cp foo.mp3 ../Music/`, or that they’re going to need to figure out the special way to tell the computer what they mean when they want to do `cp Downloads/foo bar (feat. baz and the fizzbuzzes).mp3 Music/` and that doesn’t work when they type it in.
The initial explanation of the happy path might be slightly longer to teach drag and drop or right click copy and paste for files, but that happy path will also deal with a lot more scenarios in the exact same way than the happy path cli commands will.
My mom struggled to understand the concept of copying and pasting when she got her first computer at home, with Windows. It was more than 20 years ago, but I think the idea that you need to copy in one place, then go to some other place and paste there, still sometimes confuses her in the context of files, even though she does not have any issues with that when copy-pasting texts.
Agreed about the difference between CLI and TUI; at the same time, I do indeed prefer TUI over the “normal” (window) GUI apps for the exact reason why I would prefer vim (or emacs for the other half) over a GUI editor: when you are already in the terminal, launching a TUI app is just faster than switching to a GUI window. So it's still about "terminal or not" for me, or even, what is your default starting point: is it a desktop with icons or menus, or a command line with a prompt? For me it's a terminal, so I prefer TUI apps.
...but not Midnight Commander: it's an outlier in your list, a tool that actively prevents you from learning the way how things work in terminal. Same for all attempts to invent a UI for git.
> when you are already in the terminal, launching a TUI app is just faster than switching to a GUI window. So it's still about "terminal or not" for me
I’m principally a terminal person too, but my first thought was tmux cut/paste buffer (to transfer data whether TUI or CLI), not speed-of-launch.
Exactly this. The non-composability and non-standardization of GUI tooling is my main issue with them ; having the same toolkit available to solve every problem takes some doing but is ultimately more efficient.
That being said, it's a hard sell. It's not easy to grok the simplicity of the commandline tools until you've used them to solve what would otherwise be an intractable problem.
Yes, any GUI that doesn't provide any kind of RPC or composable API layer is almost a lost cause to me. I'd personally refuse to use it. With a caveat, though: on MacOS, which I absolutely abhorred in the beginning, having now been required to use for work (instead of Linux), I found the beauty of OSA (Open Scripting Architecture). Holy mother of Turing, I wish there was anything similar on Linux. I had no idea how amazing this thing was. I can fearlessly dig things out of even complex UIs for automation in ways that I can't ever dream to be able to do on Wayland. That still not an excuse - any serious UI should provide a functioning API.
> — Well, in my FrobnicatorStudio, there's a shortcut Ctrl+Alt+So for that
When I get those people typically I'll switch to Emacs (it's always open), use dired and rename 20 files at once, using either a keyboard macro I make on the spot or using a regexp replace.
This usually not only get them to shut up for good, they also typically then see me as the "computer wizard".
I demo'ed some terminal (piping command calls) and Emacs tricks to a very good dev who's using JetBrains tools. He got it and was very respectful... He told me: "yeah I can see the appeal, but it's not for me".
The CLI / terminal / command line utils won: LLMs have proved that. The discussion is over.
I've had to batch-rename files many times over the years. That means:
1. I do it manually over however many minutes. Works if there aren't too many (especially if the pattern is too complex to trivially automate).
2. I make a Python script for it. No way I'm renaming a thousand files by hand.
3. I don't do it. Too much work. The problem lingers forever.
Or these days,
4. I make an AI datacenter eat another town's water supply.
I've never used Emacs. I tried vi(m) nonconsensually and had to google how to exit. A while later, I tried it intentionally and hkjl navigation didn't work because I use a custom keyboard layout, so I never touched it again. Sublime Text and its many cursors for the win!
I'd love a way that isn't miserable to do such a common basic task.
It opens the list of filenames in a given directory (or set of files passed on cmdline) in an editor of your choice, and then you use your editor to rename them; the changes get applied when your editor is closed.
> I'd love a way that isn't miserable to do such a common basic task.
The problem is that you actually describe a family of tasks which is not basic. The "iterate over files, select the right ones and apply rules to rename them" part is common; the problem is that the rules vary broadly in kind and complexity, and you haven't figured out how you want to specify them (some ways will be limited in the complexity they can handle.
(Usually the selection of files is trivial; when not, we can fold that complexity into the change rules, and emit null changes in some cases.)
If your selection rule is simple enough for Bash globbing, and your per-file rename rule is simple enough for, say `tr` to handle, then that's trivial to wrap up as a Bash script (or function). In fact, you could write the Python script such that it just accepts a single input filename and outputs the changed version, and handle the rest externally.
> I've never used Emacs. I tried vi(m) nonconsensually and had to google how to exit. A while later, I tried it intentionally and hkjl navigation didn't work because I use a custom keyboard layout, so I never touched it again. Sublime Text and its many cursors for the win!
I'm not really clear on how text editors are supposed to be relevant to batch file renaming. If trying vi(m) the first time wasn't your idea, then there should have been someone else around responsible for guiding you through it. But the variations I've tried had arrow-key navigation configured by default (and `vimtutor` explicitly tells you that it should also work); you really don't have to learn hjkl, which exists largely for a combination of historical reasons with a lot of back-filled justifications. (I would have used ijkl, mimicking an arrow-key layout.) And everything can be remapped in the config files.
"I don't think I've ever had" stance, about any problem is not a good argument. At some point you'd face them and the mental models shaped by the tools you choose, often force you to deal with them in a way that often creates small, subtle micro-annoyances. You won't even consciously notice them, yet they add up. You get constantly distracted, every time by small bits, your focus budget gets eroded without you even noticing it. You feel inexplicably tired at 3PM without any meaningful work getting done for the day.
In psychology there's a term called "emotional bank account model" - small chronic negatives silently drain the account, so by the time something "big" happens there's no reserve left, even though the big thing isn't the actual cause. That is I think why our field has notorious "burned out programmer" problem. We can't even explain the reasons - because the accumulation is diffuse and undramatic, people lack a narrative-worthy explanation, and the real cause is chronic negative-affect accumulation.
That is why it is important to seek ways for the "gratified productivity" where no matter how small your problem seem to be, you can find ways to automate it nicely, ideally reaching for solutions quickly. Tools do shape your mindset. Expertise changes what affordances you perceive. Experienced Emacs user when stumbled on a problem looks at a workflow and literally sees the seams where it can be pried open, the way a climber sees holds on a blank wall. Novices often don't even recognize the wall. It's not that Emacs "has this capability, but other tools don't", it's not about specific features, it's about the mindset. Experience awk hacker for the same "rename 20 files problem" may combine a complex looking single-liner and say: "who needs Emacs schmimax? ble...", the difference in the approach, but the result is not just the output but also the mental gratification - small problem fixed quickly. While a newbie would be doing it manually, and maybe even solving it faster, but there's no gratification. We are species of "tool builders" - we get excited from using tools, sharpening them each time. Menial tasks don't leave that sharpened mental edge, they "blunt" your mindset and accumulate frustration.
The only case I can imagine is when I rename a Java interface and want all implementations to be also renamed accordingly. I can do that in 1 second in IntelliJ. With dired on emacs that would not be possible at all and I would need a tool that can find all implementations first: that requires a LSP on emacs, and then from a xref buffer, not sure how I could rename all classes and their files at once. Probably would need to be manually done? Anyone knows how to do it in emacs with one command?
Java implementations sometimes take part of the name from the interface they implement, for example, `FooRunner` probably implements `Runner`.
My example was that I renamed `Runner` to whatever, `Executor`, and IntelliJ will ask me if I want to rename also implementations (in this case, it would show `FooRunner` -> `FooExecutor`).
I've been working with the command line for just under two decades. A couple of years of those were spent with vim as my primary editor, but eventually I moved to Sublime and never looked back.
But I still use the command line heavily in all my work. I usually have a konsole window that I alt+tab into whenever I need to build or run tests, instead of using Sublime's "build system" support. The only time I use vim is when I need to ssh, or am using Termux on my phone.
> The proper argument here, probably, is this one: the terminal, with its way of combining small CLI tools into pipelines, covers infinitely many use cases,
Extensible GUI tools (Sublime, VSCode, etc) cover infinitely many use cases too, except they offer more reliable and reproducible runtime environments.
I think the reason these types of discussions never die is because people in general tend towards closed mindedness. It's hard to put yourself in other people's shoes, and even harder to entertain the possibility that you're wrong.
But at the end of the day this only matters for novices. After enough experience with them, no matter what you use, your productivity bottleneck isn't going to be your tools (unless its ed...).
> I think the reason these types of discussions never die is because people in general tend towards closed mindedness. It's hard to put yourself in other people's shoes, and even harder to entertain the possibility that you're wrong.
I think the real reason is that people are used to GUIs who see the "harder tools" cannot entertain the possibility that they are wrong, and see the need to constantly make these hit posts to validate themselves. I have _never_ seen a vitriolic post made by a vim/emacs/tmux/etc. user telling users to switch over - I have seen countless by the "other side". I myself switched to terminal native workflows, not because of one of these posts but despite them, seeing how people who actually used these tools came off way more positive and seemed to enjoy their work way more than I saw from people who used e.g. VS Code and endlessly complained about anything not fitting into their worldview. It's exhausting and provokes no real discussion - nobody is actually being swayed by them, and it just adds fuel to the fire, letting people with opinions swing them around
But this only speaks about what some GUIs lack, it's not necessarily true that GUI apps can't be composable, it's just that seldom they are made as such. The true potential of a GUI app is much richer than what terminal currently offers (unless it starts to receive capabilities usually present only in GUIs, as we can see with some of them - but then it's a GUI with the severe terminal restrictions, a strange beast).
I have a similar relationship with wireshark. I understand the use of a live capture and display and the attraction of the click GUI.
But at some point I just figured I was wasting so much time in there. Switched tshark and jq or good old bash/awk/grep and gnuplot, back to the command-line, then python for batteries, still using the output of tshark... and then ended writing a pcap(and ng) parser with ethernet-ip-udp/tcp and a full java IDE and never went back. I went the same meandering path with every data capture and exploration tool I had to use repeatedly.
I feel I'm not the only one having this repeated sequence of tooling improvement, hopefully there is a well named scale to describe it.
I've never managed to make the terminal work for me. But I've been using windows since I was like 5 and I'm really bad at remembering shortcuts besides a handful of ones I use every day.
> When you reach that point, you will be, on average, much more productive than an average GUI user
How sure are you about that? I often watch streams of people using emacs or vim, with totally custom setups and it seems like a wash to me. They look like wizards doing some stuff, and then other things seem slower than my own workflow.
That's a weird thing to say. GUI slows down me A LOT when I sometimes have to switch to it from my terminal for whatever reason. Where did you get your "absolutely no one" data point?
You should read again what I said. Do you think that simply using GUIs makes anyone less productive? You can’t think of any cases where a GUI is definitely better for a task than a terminal? If you think that , consider why the vast majority of people are using GUIs for everything, and only a tiny minority is using terminals for everything. It’s ridiculous, yes, to imagine you would be more productive if no GUIs existed (you just misunderstood my point).
I reread your original comment. It would have been better if you had included those small details that, for some reason, you left out. In my opinion, you simply failed to get your point across.
Anyway, my point stands. "Absolutely no one" without any context makes no sense whatsoever. There are a number of tasks that are much, much more efficient to perform in the terminal than in a graphical interface. So no, I didn't misunderstand your point - you're just wrong.
> any cases where a GUI is definitely better
Sure I can. Not all of them are though. So be careful with exaggerations.
whoa, you can and absolutely should pipe things in and out of vim - it's natural. Emacs on this actually in disadvantage - it doesn't give you a built-in way for piping from and into buffers, but for that there is emacs piper script: https://github.com/agzam/mxp
Dunno, never had to do this. At most I might set PAGER=vim which means maybe something else is piping for me. If you're piping with vim then fine, but it's not a requirement to use it, unlike smaller utils that are begging to be piped.
is not a defensible argument (regardless of what you use), see the relevant comment here¹
the bigger point is to get more precise and utilitarian control over text which I already discussed here in this thread², piping in and out of your editor buffers sometimes comes very handy.
Most programmers come to appreciate a single fundamental truth about their field way too late into their careers. That the most basic foundational unit, the substrate they need to conquer is text. Everything stems from it. We have to deal with text our entire lives. It doesn't matter where that text appears - in web browsers, in Jira, in Slack, terminal, in PDFs, Word or LaTeX documents. Code is just structured text. The feeling of empowerment and liberation when you can deal with text on your own terms is a disproportionate multiplier.
Vendors are designed to own you and ownership can have different forms. Slack.app that doesn't let you easily extract code snippets from a thread - owns you. Jira that forces you to use their imbecilic, quirky wysiwyg owns you. Note taking app that keeps the data in their db and not your files - ain't your friend. The friction is the ownership. When extraction of text requires effort, the tool has leverage over you. It's a subtler form than data lock-in - behavioral lock-in. You adapt your workflow to what the tool makes easy, and gradually the tool's affordances shape what you even think to do. Information gets buried in threads, search is mediocre, export is hostile. The "solution" they offer is to stay there longer - search in Slack, link to Slack, screenshare in Slack, summarize with AI in Slack, don't ever leave Slack. The tool becomes the answer to the problems the tool creates. It doesn't become "invisible" like the article says, you just don't realize that you're "lost" yourself in it.
Most popular editors and IDEs don't give you direct leverage over plain text either, at least not without the effort from your side. Shortcuts, popups, UI elements in the IDE at best are local drivers - you can't easily grab a thing from the outside and feed it to your LLM context in the middle of a task, or insert within a comment in the code - you have to switch, copy, paste, deal with format inconsistencies, manual conversion, etc. Then we keep bargaining what method is the best, fastest and most convenient - using the mouse or keeping the fingers on the home row, modality or complex shortcuts. All for the sake of the problem that's artificially enforced on your workflows.
Terminal-heavy users eventually start appreciating the leverage Unix philosophy grants them over text, but that's still contained within locality, they still have to constantly jump around, while eventually figuring out ways for automating some aspects of it.
Anyway, this should be a little more of a deeper discussion than a forum comment. Point is - do not give in to the status quo. Liberate your text - deal with it on your terms. Get annoyed whenever you need to switch back and forth just for the sake of finding the piece you need and moving it around - it should be instantaneous and instinctual. Like boxers moving on a ring and casually throwing punches. Long time Vim and Emacs users "get it", even though often don't follow true - some things never become gratifying instincts. Sometimes, even the opposite forms - redundant muscle memories.
I realized that I was typing the comment above in the middle of the night; finally, brain fatigue hit and I wrapped it too soon (thus some typos, sorry). That all was some "poetry." Now let me give you some concrete example cases.
1. You're typing a message to your colleague, and you're doing it in Slack, Teams, etc. Why? Why not use your trusted editor where you probably already have smart completions, quick spellchecking, thesaurus, definition and etymology lookup, translation and dictionaries, LLM integration and more.
Years ago I realized that and stopped typing anything longer than three words in anything else but my editor. But that forced me to copy-n-paste a lot, so I automated the process. I'd press a key in the middle of typing - regardless of what the current app is, the script simulates pressing Cmd/Ctrl+a Cmd/Ctrl+c; opens the editor buffer; inserts the text; I'll do editing; press a key - it goes back to the app; pastes the text. Stupidly simple, deviously efficient. Suddenly, my entire OS is my editor and my tool is "invisible" - like the article describes.
2. You're typing a message to your colleague. Now you're doing it in your editor, you want to share the url to the thing opened in your browser. What do you do? Normally, you'd switch to the browser, press another key to focus on the navbar, copy the link, switch back, paste the link. Goddammit, the url is cryptic. You, being a good teammate, want to add a description, now you have to go back to the browser to copy it. Then you have to make it into a markdown link format. Darn it. Was it parens and square brackets, or the other way around? We don't even realize how often we do this, because this simple action has become a routine. What's the point of arguing if mouse or vim or shortcuts is faster if the action is fundamentally flawed? For me, inserting a link in the middle of typing, from any tab in my browser is within a keystroke. It intelligently and properly formats it while retrieving the document.title.
3. Your colleague sends you a message: "Hey Jon, what about FOOBAR-41234?..." You know it's a Jira ticket number. But between FOOBAR-41345 and -41234 and a bunch of other recent ones you have no mental recollection of what that number is about. You go to your browser, navigate to the Jira instance, darn thing says you have to re-login, now you're going through 2FA - it won't even let you-in unless you find your phone and confirm it. All that effort just to look at the title. We all recognize this familiar flow, don't we?
Why even deal with this BS at all? Jira, Asana, Trello, etc. - all have CLI tools, you should leverage that. In my editor, whenever the cursor stumbles on a pattern like above, it immediately fetches the ticket description and shows it in a popup. I can quickly convert the plain "FOOBAR-41234" into a markdown, org-mode, whatever link format that has a description.
4. You're looking at FOOBAR-41234, you even see the description (because your editor is smart now), but how do you answer questions like: "what are the PRs related to this ticket?", "find slack threads that mention it", etc.? That stuff should be quick and easy. Do get annoyed whenever it takes longer than two seconds to answer any of these or similar questions.
5. You are pair-programming over Zoom. Alice (your colleague) is sharing the screen, you are reviewing some big unit of work. She's scrolling through the code changes, occasionally opening documentation, navigating to different sites, etc. You just can't bear constantly interrupting her with "slow down, I'm taking notes", "please, share this link", etc. After the session you frantically try to recall, but most of it is gone now, your notes are whacky, containing a bunch of broken urls and half-typed nonsense. Three weeks later it is a complete and utter garbage. Then you spend years debating of note-taking strategies trying to figure out what "works" and what doesn't.
That should annoy you. Darn it, if I can see it on the screen, why can't the computer "see" it too? It irked me, so I hooked up Flameshot, Tesseract, and Emacs and now I can select any area of my screen and the text gets OCRed and pops in a buffer. It's not always accurate, but it is quick and I don't even have to tell Alice to slow down anymore.
---
These are just a handful of examples, and I haven't even touched anything code related. Hopefully you can already see what I meant in my post above. Do liberate your text from the tyranny of complex GUIs, do get annoyed when you have to manually retrieve any piece of whatever. You're a damn programmer, computers and computer programs should obey your command, never forget that.
Recently revamped my terminal setup after all IDEs have just gotten painfully slow to work with (the debugger + git integration in intellij was my last moat, but spend some time to learn nvim-dap + lazygit and it's excellent). AI has been immensely helpful here too to figure out the long tail of weird config gotchas.
Also thanks confirming the multiple cursor YAGNI for vim, could never wrap my head around needing it in the first place.
— In a terminal, I can do so-and-so with a simple command
— Well, in my FrobnicatorStudio, there's a shortcut Ctrl+Alt+So for that
and this can go forever, going into pretty much useless comparisons like "in vim, I can delete 24 lines by pressing four keys" (no Sublime user ever needs that) vs "in Sublime I have multiple cursors" (no vim user ever needs that either).
The proper argument here, probably, is this one: the terminal, with its way of combining small CLI tools into pipelines, covers infinitely many use cases, but indeed has a learning curve, taking probably a year or so to become really comfortable. When you reach that point, you will be, on average, much more productive than an average GUI user, but it requires some dedication, pain, and suffering to reach that point, and people often do it involuntarily.
In my case, my first job required managing customers' servers over ssh, those servers had bare minimum installed (often vi, not vim), and I had no choice other than figuring out how to do things effectively in this setup. If not for that experience, I'm not sure I would've gone through the pain of starting doing things in the terminal.