As someone who has spent the last 10+ years working in Tmux - but is entirely comfortable on Mac, Windows and Linux desktop environments - here are the key reasons why the terminal experience is superior for me.

- I work a lot with data - and streaming data through text tools is twitch fast. If someone has a question about data - before anybody else can log in to their superset, or analytics database, and try and work through the SQL queries or charts to get the answer - I've already jammed the data through awk and got an answer.

- As an SRE - I work with a lot of systems that have pretty rich APIs - so being able to send a request, get the answer back in json, dump it into jq, select the parts I care about - maybe -c to compress it and ripgrep a subset out - is just fast.

- I work in a lot of contexts with a lot of different systems, datacenters, applications - tmux lets me keep all of them cleanly organized in a separate windows and subpanes. I'll have 15-20 windows open per week, and maybe a 5-6 panes in each- keeping 100+ different contexts (and scroll backs, bash history) - all nicely organized is really useful.

- I'm also a systems guy - and there is no other way to dig into a system but the terminal - netstat, ps, dmesg, /proc - these are all components that have only one credible path to investigation and discovery. If you aren't super comfortable in the terminal - zero way to learn about this stuff.

- Working remotely - means ssh. So - once again - terminal.

The Focus on the terminal is that it's the best tool (and in some cases the only tool) for so many of these tasks - and by performing these tasks a lot - you learn about systems - so the people who spend a lot of time in the terminal tend to know a lot more about systems than people who don't.

Anything you do in the terminal can trivially be scripted (automated). It's a self reinforcing loop of making life easier. After many years of working in the terminal, and making little scripts, my workflow is extremely fast, comfortable, and customized to me. You can do some of this via GUI tools, but terminal makes customization easy. Also, using keyboard shortcuts is just vastly superior to using the mouse, you can't convince me otherwise.

> Why on earth would i not want the ability to open/edit a file manually in the tool im using to write code.

I don't know what you mean by this. You can open any file in neovim at any time without leaving the program.

Being familiar with the terminal also makes building CI for the team trivial because I'm already familiar with how all the commands work in the CLI. I'm basically the goto 'devops' guy because I'm one of the few people who actually knows how to work in a Unix terminal.

I will say, TUI is not the same as CLI. I don't find a meaningful difference between a TUI and a GUI other than being able to use tmux or something for window management. I prefer gui tools for database management, querying, git diffs, email, all kinds of stuff.

As for the superiority complex. I've got no judgement on people who prefer the GUI. I have many excellent coworkers who primarily use GUI tools. Having said that, every engineer I've met that works primarily in the terminal has been great. It's a very strong signal of technical competence in my opinion, but terminal familiarity being a signal of competence, in no way makes GUI usage a signal of incompetence.

I did a lot of automation at my last job, which was closer to engineering in the classical sense than engineering in the software sense. The automation mostly amounted to web scraping and interacting with local systems, with a generous amount of logic in between. The largest roadblock wasn't the scraping or the logic, it was the inbuilt assumption of the local programs that there would be an ape with a mouse and keyboard driving the interaction. Outputs that could have been text needed to be copied to and read from the clipboard, or exported as a spreadsheet. Inputs that could have been text were only accepted in spreadsheet form. Pixels needed to be read from the screen to tell when one step was complete and the next could begin. Mouse clicks and keystrokes sent to and fro when it all could have been a series of commands. I cannot count how many written processes and procedures existed could have been a bash simple bash script.

I'm not arguing that these programs should not have a GUI, for that was the simplest way to use them, but the lack of command line functionality places a hard limit on the productivity of an organization, and ensures that the only progress on that front comes at the expensive of exceedingly limited developer time.

"But nobody knows how to use a terminal anymore," I hear you say. Well of course they don't, nobody under 35 without a background in programming has ever had cause to use one. We made everything so simple that nobody ever has to learn anything. That isn't to say that people cannot learn, just they have been robbed of the natural opportunity to do so. Otherwise intelligent people never progress beyond the manual step-by-step interaction that passes for "using a computer" today.

A computer is a tool in much the same way that the a machine shop is a tool: it is a tool that can build other tools. The role of software developers should not just be to build simple tools that can do one task in isolation, it should be to build tools that less technical people can use to build the tools they find themselves in need of. GUI-only programs are simply not fit for that purpose because they lack composability of simpler terminal-based programs.

Fundamentally you are right, problem is that most UI applications in general have garbage tier UX and/or are a buggy mess.

Like any other computer UI: Terminal-based programs (whether ultimately windowed in a GUI or not) didn't start off being familiar. But for those who use them, they eventually become familiar.

And that familiarity transfers between different systems. Windows, Mac, Linux, whatever: The flow of any particular terminal-based program is the same everywhere that it can be used.

It's tidy, and light. It's also network-transparent, and things like ssh keep it secure. Multi-user support is the norm instead of the exception on systems where terminals are common. It doesn't interrupt anyone else's work like something like using Anydesk to access some GUI desktop somewhere else can.

The keyboard shortcuts are annoying at first, but they're faster than mousing around in a GUI -- and once learned, they're approximately impossible to forget.

(You're free to hate terminals if you wish. I don't care if you justify it; I'm not your boss.)

Absolutely nothing? That's certainly not true. My experience is that those who grew up learning the command line are so familiar with it that they excel at navigating those bespoke keystrokes more quickly than any GUI user who has to scroll, point, and click. Add to that features like command history and autocomplete, and shell users are often far more productive than GUI users.

I think you miss crucial point here.

Terminal/CLI is superior if you know what you want to accomplish. There is no faster way of doing stuff on a computer if you know what you’re doing and having tab completion and knowing all the incantations.

GUI is superior when you have to figure out what to do and what needs to be done. GIT branches state checking, finding out a switch to enable a feature so much easier in graphical interfaces.

I find that what you call „annoying engineers” are just people who have their tools and use them efficiently … but once they have to step out of their path they become annoying or even obnoxious.

The opposite is random person who expects everything to be easy and available in less than 3 clicks — well good luck engineering an interface for complex system that does that, not everything is Facebook, there are systems where you need to spend time wrapping your head around.

Different strokes for different folks, but unfortunately they take their opinions and preferences as a sign that others are inferior.

I refuse to believe this wasn't written to intentionally bait, reads like copypasta.

The thing you can do in the terminal that you can't do in a GUI, is glue together over 50 years of useful tools, no matter where you got them from or if the authors have ever heard of each other.

If your workflow fits entirely within a single app's GUI, then yeah, the terminal version of that app is not going to be as useful. But if that app doesn't exist yet, you can put together an 80% version of it for 20% of the work.

Historically, it's also a lot more resistant to rot. Brian Kernighan isn't going to start charging a subscription fee for AWK - and if he did, there are many forks and similar tools.

And, addressing a specific point - why would I want to view a code diff in a terminal? Sure, 'diff old.txt new.txt' is probably less useful than popping it open in a nice GUI with highlighting. But "diff old.txt new.txt | grep '^+'" will only show me added lines, or "| less" and type "/foobar" to jump to all mentions of foobar.

And this is like, the least you can do - the stuff you learn in the second class of "Using the Terminal 101". You can easily use this with git, as a building block to make a quick script to graph the number of changes over time in your repo. Yes, there's probably a GUI somewhere in your workflow that can show this (maybe you click around in Github to find it). But, maybe you also want to just filter that to changes in a specific module in the codebase, or an author, or quantify what module changed the most each month. If you've learnt the building blocks, the scriptability of the terminal lets you put that together quickly.