I still reach for the terminal first. It is not nostalgia, and it is not a performance. When I need to know what a Linux server is actually doing, a black window with a prompt tells me faster, and more honestly, than almost anything else I have installed.
That habit formed the practical way. I learned servers by fixing them, and fixing them usually meant reading what the machine itself had to say. A command either worked or it did not. A log line either explained the failure or pointed to the next place to look. There was no friendly green check mark smoothing over a problem that was still there underneath.
Graphical panels have their place, and I use them. But they hide a lot by design. They show you the settings they think you need, in the order they think you need them. If a service is failing for a reason outside that tidy view, the panel may tell you everything is fine while the underlying process is stuck, out of memory, or pointed at the wrong configuration file. The terminal does not tidy things up for you. It shows you the error, the path, and the permission problem, all at once.
My usual workflow is simple, and deliberately boring. I connect over SSH, I open tmux so a dropped connection does not kill the work I was doing, and I start with the basics: what is running, what changed recently, and what the logs say. From there I can check a service, look at disk space, test a connection, or read a configuration file without leaving the keyboard. It is one continuous line of thought, instead of a series of clicks through menus that each reset my attention.
Logs are the best example of why this matters. In a terminal I can follow a log as it grows, filter it for the one error I care about, and compare it against what I was doing at the same moment. That feedback loop is fast. I try something, I see the result, I adjust. When I am troubleshooting, that speed is not a luxury. It is what keeps a small problem from turning into a long outage while I hunt through tabs.
I am not saying a graphical interface is never better, because that would not be true. For browsing files visually, for looking at charts, or for handing a routine task to someone who does not live in a shell, a good interface wins. I also like a visual editor for writing and a browser for reading documentation. The point is not to use the terminal for everything. The point is to know when the terminal is the shortest honest path to the answer.
If you are learning this work, my advice is to build a small terminal-first habit. Learn to connect safely, keep your sessions in tmux, read logs before you restart things, and write down the commands that actually fixed a problem. You do not need to memorize everything. You need to be comfortable asking the machine directly, and reading what it says back.
The practical takeaway is simple: start at the terminal when something is wrong, and use a graphical tool when it genuinely saves time or makes the work clearer. That order has saved me more hours than any dashboard ever has, because it keeps me close to the truth of the system I am responsible for.