Are GUI’s for losers?
I frequently encounter different viewpoints around whether it’s preferable to use a graphical user interface (GUI), or a command line interface (CLI).
CLI advocates usually take the view that using the GUI makes you lazy (and by inference — is used by lazy people), and that any technology worker who prefers GUI to CLI shouldn’t be taken seriously.
GUI advocates take the view that messing around with a CLI is a waste of time, when the same operations can be done with an available GUI that is easier to learn, quicker to complete, and less prone to human error.
Examples of GUI’s I use every day
Personally, I’ve found well-designed GUI tools to be helpful for improving my understanding of tools and platforms as well as for performing repetitive tasks.
For example the Kubernetes Visual Studio Code Extension and the Lens Kubernetes IDE both helped me to form a more complete picture in my mind of the data hierarchy and internal dynamics of a Kubernetes cluster. Certain of the information is just easier to ingest when it’s nicely colour-coded and arranged with a logical user experience.
I also like to use the GUI Git Operations integrated in Visual Studio code as well as the Atlassian Bitbucket VS Code extension. For my daily workflow, it’s just quick and easy to press the ‘Start Work’ button in the Atlassian VS code integration which automatically sets up a correctly named branch. For committing — I can just type my commit message and press Ctrl-Enter and move on to the next task.
With some practice …
Sure, with a little bit of practice I could get the requisite git cli commands into muscle memory that would allow me to eventually use the CLI just as swiftly as the GUI tools. While this may increase my geek-credibility with the CLI purists, and may be advantageous to make me more familiar with the CLI on the rare occasion where I’m forced to use the CLI due to a some lacking feature in a GUI tool, it won’t help me do my daily tasks any quicker or any more accurately.
GUI’s are like …
I guess there are some parallels between GUI and relying on automation. When we write an automation script, or adopt an automation enablement tool, the goal is always to save time by reducing the need for repetitive humdrum work, while at the same time reducing the likelihood of human error being introduced into the process.
Like with anything, there are pros and cons. When your GUI/Automation fails, it can take you much longer to troubleshoot the problem, as you’d have to familiarise yourself with the inner workings of the tool. But this is just the same as with any other modern technological advance: We rely on our motor vehicles to get us to our destination faster, but if it breaks, we’re stuck, and it could be time-consuming and expensive to get going again.
So what is then? GUI or CLI?
With all that said, there’s also the adage — “The shortest route is the route you know”.
Considering that we’re paid to get a job done within time constraints, each person should use whatever tool they prefer to get to the end result in the quickest, most accurate way. If you’ve developed the muscle memory for using CLI commands faster than GUI tools — then by all means, use the CLI!
I don’t care about geek-credibility, but I greatly care about the speed and accuracy of my work tasks. For me the answer is simple — GUI all the way, as long as it helps me do my work better.