This is true, they are much better for discovery and affordance, but as you progress with your tooling and tool usage there is a much higher ceiling on your productivity with other tools and their composability. In my opinion, not putting effort into learning tools ultimately holds a lot of people back from their potential.
They make some parts of text manipulation faster, but those parts of text manipulation take up less than 1% of my time spent working.
Things like debugging, which take up a large portion of my time, are not so nice in terminal based environments
But find a terminal first approach leads me to other tools like curl and jq usage as I go. I see coworkers using a ton of time trying to repetitively execute the code to see those spots in really inefficient ways. And end up completely lost when they could be using tools like git bisect.
Or another good example devops type support is if one web server out of many seems to be misbehaving, I can use aws command line to get internal ips behind the lb to curl to grep and find it in minutes after others have tried for hours. It makes it second nature if your mind goes there first.
As always, the “best” tool is the one your most familiar with that gets the job done. Text vs GUI doesn’t really matter at the middle of the bell curve.
Vim and other terminal tools make doing complex text manipulation easy, but I rarely need to do anything complex when writing code.
I also work from different machines and ephemeral vms regularly and don’t want to spend time setting things up each time.
I can install vscode and the one lsp plugin I need in under a minute. In contrast, Vim doesn’t even have line number enabled by default.
And I work on different types of systems, which have different requirements and different ways of installing these tools.
Yes, there are other tools to help automate this process as well, but vscode “just works”
1. You very frequently have to install your setup from scratch.
2. Preconfiguring something that aids in installing from scratch is not viable or sensible. (Perhaps you work in an environment where you're not allowed access to your personal dotfiles repo, for example.)
But I think most people will fail at least one of these checks.
But, I think the main problem is that although there have been many attempts we have not gotten to a standard way to compose different GUI tools easily or repeat actions.
I would say that GUIs are superior for a few specific use cases, but otherwise sub par. Step through debugging comes to mind as a good GUI use case, but even that I'm not sure if it's because a GUI is inherently better, or making a terminal based debugger is harder and so nobody has made a good one yet.
What specific ways do you find boost your productivity the most?
For me, the things terminal workflows can do faster take up almost a negligible amount of my workday.
Curious to hear if I’m missing out on a terminal workflow, or if my workday is just very different from yours
Terminal skill ceiling exists, but a lot of custom flows are just local maxima that look elegant to the person who wrote them and miserable to everyone else who has to debug or extend them. GUIs give up some raw power, yet for diff review, history browsing, and getting a team moving without turning every workflow into a tiny priesthood, they are often the better tool.