If you’re using a GUI, that means whatever you’re doing you’re not doing a lot of it, since you don’t need to automate it. I would expect a world-class enterprise engineer to be able to automate most tasks, and from that they would be very comfortable with the command line.
Can you do everything with a GUI that you can on a command line? Yeah probably, if the developer is at all the features properly. Can you automate it easily? No not at all. So the more you do something the more you tend to want to deal with the vocabulary of the command line because it’s more expressive and allows for automation.
I will die on this hill!
Documentation too. Frontends change all the time, but CLI tools usually don’t, so you can usually rely on old documentation. But have you ever tried googling how to do something in MS office, found and article from half a year ago and found that none of the things it mentions exist anymore? It’s ridiculous how much time people waste trying to figure out stuff multiple times because it changes so much.
Depends on what system you’re running, and especially what task you’re doing. Trying to operate firewall rules via CLI is an exercise in self-inflicted pain, as is trying to set a complex cron schedule without a handy calculator.
CLI debuggers can’t hold a candle to the Visual Studio debugger. This is generally not something you automate, and I haven’t met many engineers that know
gdbwell. But pretty much anyone can use VS debugger.
To get annoyingly serious on a funny post, the one huge danger of GUIs that I’ve personally witnessed in many of my juniors is that they abstract away the need to understand the tool you’re using.
I regularly use a Git GUI, and I might have to google the rebase command for more complex tasks, but I know how Git works. I know what I can do with rebase, even if I don’t exactly know how to. If you only live in the GUI, you can get far never understanding the system. Until one day, when you fuck up a commit or a push, and you’re totally hosed because there isn’t a pretty button with the exact feature you want in your GUI.
Yeah, fuck that. It’s perfectly fine to build a GUI that makes things a bit easier, but make the GUI so that it resembles the fucking workflow. I hate that when I want to automate something thats super easy in the GUI and it takes AGES because there is no equivalent to what I’m doing in the GUI
I hate that when I want to automate something thats super easy in the GUI and it takes AGES because there is no equivalent to what I’m doing in the GUI
glares angrily at Azure CLI
Yeah, keep telling yourself that buddy.
So… my only requirement for my tools is that they have a well-supported CLI, and can be installed headless without graphical dependencies. Tools must be scriptable.
That said, it’s nice to have a UI. My ideal configuration is a scriptable tool with a good API, and a separate GUI tool that can drive it.
Pshaw! CLI and GUI? Real network engineers make hand crafted API calls!
“graphical user interfaces make easy tasks easy, while command line interfaces make difficult tasks possible”
- William E. Shotts Jr., The Linux Command Line: A Complete Introduction
It has taken me a long time to get comfortable using a Linux CLI (definitely not as familiar with windows cmd prompt/powershell), and I know that if I log into a box anywhere, If it has
shorbashor some variant of those shells, I’ll be able to get by.Now, on my home server, moving & renaming a bunch of media files has me really wishing I had a DE installed there to Ctrl + click/Drag-n-drop…
Also, I love using VScodium/Code as an IDE bc of its configurability & rich plugin ecosystem – but recently I had some performance hiccups with extensions not playing nice together and started (again) down the masochistic path of configuring neovim to use as an “IDE”…
Why not mount your server as a share and use your desktop GUI to manipulate files? Then you can do both.
I always feel that graphical interfaces make easy things difficult, in most cases. A bunch of figity clicking around, instead of a few keystrokes I could press with my eyes closed. They are more discoverable, though.
If you use emacs, dired and wdired together are fantastic for managing files like that. You can even run dired over tramp, so you can manage files on a remote server that doesn’t have emacs installed, using the emacs on your desktop. But there are also good cli options, you might want to look at the rename command, as one that’s probably installed by default on any given distro. That’s outside my expertise, though, as I just use emacs.
Honestly, some things can be done faster/as fast on GUI. So really just use whatever increases your productivity.
IMO GUIs are always faster when it’s something you’ve never used before, or use very infrequently.
CLI is better if you’re used to the task you’re doing, or automating things. But for infrequent tasks looking up the commands (or looking at old notes to find it) is very slow and rather annoying.
You gotta admit, it’s fun to meme the opposite camp. Whether you are a GUI or CLI person.
But you look way cooler when using the terminal for most of your stuff 💁♂️ also using a riced out window manager and riced out Vim config for which you spent hundreds of hours on customizing every aspect of it :p normal people don’t know what the fuck is going on on your pc so you can feel instantly feel superior to those normies! Ah also btw i use arch ;)
I use both. I use the CLI for a lot of stuff but I also use the GitHub Desktop fork for Linux lol. I don’t care how powerful git is in CLI, that gui is just so nice imo
It took me forever to realize I could edit config files in a graphical text editor. When you have a really long file it’s just nicer to have properly formated text wrapping and a scrollbar with a preview box.
Use a computer in whatever way you want and/or need to best get the job done. It’s a tool for accomplishing tasks. The amount of random gatekeeping for no goddamn reason in tech/programming/FLOSS is ridiculous.
To me, your choice of worlstation OS says a lot more about your priorities.
Someone told me that windows server UI interface has more options than CLI. I got scared of windows server (how do you repeatedly Setup the same server, with a screenshot documentation ???)
Using the right tool for the right task is a big part of being a good engineer.
I think I really only use GUIs if I am learning something new and trying to understand the process/concepts or if I’m doing something I know is too small to automate. Generally once I understand a problem/tool at a deeper level, GUIs start to feel restrictive.
Notable exceptions are mostly focused around observability (Grafana, new relic, DataDog, etc) or just in github. I’ve used gh-dash before but the web ui is just more practical for day to day use.
For context, I’m in SRE. I feel like +90% of my day is spent in kubernetes, terraform, or ci/cd pipelines. My coworkers tend to use Lens but I’m almost exclusively in kubectl or the occasional k9s.
it makes you a Windows engineer which is worse
I’d argue that if you only know how to start your own project using the play button, then you aren’t a software engineer.
I’ve written a pretty big application for my employer in visual studio. Never once have I run a “dotnet build” command. Only ever used the little play button. Guess I’m no software engineer
The real software engineers are those who can 2 minute Google “how to build with cli” their Hello world console app.
But you knew about
dotnet buildTbf, I looked it up on Google. I know you can do everything you can with Visual Studio also in the CLI, but never bothered checking out the specific commands. 2 second search on Google returned
donet build.A software engineer isn’t defined by what commands he knows or what functions he can remember off the top of his head or what languages he used to write hello world. Those are easily Googlable things that have little to no value irl. The ability to actually solve a problem or build an architecture, a system, even if only in pseudocode is much much more valuable than knowing any specific command.
Case in point, I routinely Google stuff I already used or self reference previous code I’ve written cause I can’t remember how I did certain things. Nothing wrong with that.
There’s no shame in being a play-button corporate programmer who’s in it only for the money! In fact, most employers prefer this kind of people.
Knowing how to do something in the CLI and choosing to use the gui is different than only being able to use the gui.
I don’t. Looked it up on Google, not that hard. I also never use git from the terminal, I know I could, but I don’t and if you were to ask me off the top of my head how to use it from the cli, I probably wouldn’t be able. Not because I can’t use git, I just can’t be bothered to remember all the commands when a gui is available and does the exact same thing I needed to do anyway. If and when I’ll need to use the terminal for git, I’ll check the docs for the exact syntax.
Again, knowing the exact syntax it’s not what defines a software engineer, IMO.
Then yes, you are not a software engineer. You used programming to solve one problem one time and you didn’t understand what was happening under the hood. Building one deck does not make you a carpenter. Writing one app does not make you a software engineer.
