DEV Community


On GUI-shaming and a mountain of hot takes

Ben Halpern
A Canadian software developer who thinks he’s funny. He/Him.
・3 min read

I made a tweet the other day which definitely struck a chord

Liquid error: internal

This is the kind of hot take tweet which leads to many more hot takes, so I felt like unpacking the thought a bit.

I agree. CLI/GUI is a special enough case I've seen so often whenever the conversation comes up that it seems like it belongs in its own category.

This is exactly the type of shaming. GUIs are not "for people who don't want to invest the time and effort in trying to find out how something really works." They are a tool like any other. I actually agree that there are few good GUIs, but also see this as textbook shaming that doesn't help anyone. Like special effects in movies, we only notice the bad ones anyways. I really don't like the GitHub desktop app compared to using the command line, but it is still fairly useful in some cases. I really don't like actually looking at git diffs in the terminal, so while I manage things via the CLI, I still visualize with a GUI (VSCode has become that GUI for me).

Anyway, not to be too harsh, but I thought that was a bad take, and just what I was talking about.

I agree. This is good useful advice. It's a good pitch for learning CLIs in general.

This is kind of a big point of this in the first place. Everyone has a different path and putting yourself in the other shoe is not so straightforward.

This is a reasonable approach, if approached reasonably. (This is how I talk sometimes. Yikes.)

Exactly. I feel the pain. But probably less than you. Within our own office, @maestromac probably feels this pain the most. He's really good with CLIs and vim, and deep down would probably love if everyone did things his way.

But Mac doesn't get religious about it.

Be like Mac.

I just got done talking about how I don't really like the app. And I'm glad others do. I'm sure plenty of people really do.

As the person who said I don't like it, I can't actually give really good advice on how to improve it either. This is probably because I haven't taken the time to learn it, so I probably shouldn't jump in to shit all over anyone who has done so.

And that's back to the original point. It hurts the whole industry if we put people down for the tools they use. Many people do end up learning important command line concepts, but many do it after a lot of work, maybe years professionally, working with more visual tools. And if they never do, it seems like they are probably doing fine anyway.

In conclusion

It can be very painful to watch anyone operate a computer who doesn't make good use of shortcuts you feel everyone should be using. Some people copy-and-paste exclusively with the mouse. Some people use caps-lock-on-caps-lock-off instead of shift. It can be painful, but if you see someone doing something "wrong", as you perceive it to be, being an asshole about it isn't helping anyone.

One last aside

As a tangent, I feel that some developers don't put enough time and energy into their basic computer/desk/environment set up. You don't need the best, most expensive, stuff, but you should have a good setup and a good routine.

I feel like this post has some good ideas:

I felt like bringing this up because it's related to tool-shaming. A lot of folks will see someone with a bad setup or flow and give them shit about it. I'd rather proactively take the opportunity to provide some helpful resources to anyone who might not already give this a lot of thought with regards to their own productivity.


Happy coding ❤️

Discussion (49)

darkain profile image
Vincent Milum Jr

Why not a hybrid approach? There is this concept of "best tool for the job" rather than "use one tool, and only one tool EVER"

Reading through this, I see mixed opinions on both sides. I'm a developer who actively uses both sides throughout each and every day for different purposes.

For instance, I do all of my main development on Windows, so Sublime Text is my editor of choice. I have no qualms about dropping to console on servers to edit configs in nano though.

I use TortoiseGit to manage my repositories, but again, can still drop to console for more complex tools or server work. I find that a solid GUI in Tortoise suite of tools offers a significantly better diffing experience than anything I've seen on console to date, plus its easier to setup .gitignore lists or dealing with submodules. But when things break, recovery needs to happen on the console.

I've also come to love htop as a replacement for top as a "task manager" equiv on the console. With using it through PuTTy, it still supports mouse commands, so I can simply click on rows to select items, just like a normal GUI application. I think this is a prime example of what a hybrid application COULD do, if others followed this style.

ben profile image
Ben Halpern Author

I think most people already do use some form of a hybrid approach anyway, which is where so much of the purism and shaming is misguided. The lines are blurry so taking a hardened position can be plain silly.

redoxeon profile image
Mike Harding

This is kinda how I feel. I'm pretty new as far having a setup I like, and I've only recently been dipping my toe into Linux. I've used GUI's for mostly everything up until recently and have been trying CLI stuff as I get comfortable with it. If I find that I like something better in CLI, then I make that my primary tool for that job, but for things that I still like better as a GUI, I'll keep using the GUI.

Like you said, it's using the best tool for the job. Tools are only as useful as the person using it, so if I'm terrible at a certain GUI program or a certain CLI program, then it's probably better to not use it unless I'm really wanting to invest my time and energy into it.

nathanheffley profile image
Nathan Heffley

I have a hybrid approach. I do all of my branch creation/switching, committing, pushing/pulling, single-file diff reviewing, etc. from the CLI. I hop over to my GUI when I'm trying to follow the branch history, doing conflict resolution after merging, or trying to view diffs.

If I'm trying to visually review something I use a GUI, if I'm just trying to do things with little visual feedback I use the CLI.

lscarneiro profile image
Luiz Eduardo Carneiro

I'm on this hybrid approach, I use SmartGit every single day, but if I need for example to make a reset, I always do it on the CLI, cause I don't feel comfortable using the GUI for it, the terminology is not always precise, and the things really happening behind are difficult to see, so in some complex cases, I always go CLI, but for everyday commit/pull/push/branch/merge/3-way, GUI.

asparallel profile image

Try setting your merge editor to vscode in git config. It's significantly more full featured than tortoise.

akajb84 profile image
Neesha Desai

I generally agree with everything you've written above. I do feel like a big piece that's often missing in these discussions is the acknowledgement of the assumption that everyone starts with - that we all have the same understanding / conception of how things work / flow / etc in our heads. We don't. And it's not that my version is more right than yours, or that yours is more right than mine, it's that our own systems are based on our own understandings.

There are numerous things I find painful when others do them (like two finger typing). However, unless someone asks, it's not my place to provide any advice on how they should change or even why they should change. And for everything that may make me cringe, there's always something else they do that I can learn from.

However, there's something that actually bugs me even more about these discussions. And it's this idea that if you're not doing everything the most efficient way possible, then you're doing it wrong. That you have to have the right (or better) setup. An implication that somehow four extra clicks somehow equals being 40% worse at what you're doing.

We'd all be better off if we stopped this endless races towards "perfect" productivity and actually put the brakes on and slowed ourselves down. The actual time I spend typing code is a small fraction of the time I'm actually spending on the problem. Those few extra seconds or minutes here and there, also give me a chance to more carefully think through my actions - and whether I choose to do so via GUI or CLI doesn't matter.

rhymes profile image

We'd all be better off if we stopped this endless races towards "perfect" productivity and actually put the brakes on and slowed ourselves down


gypsydave5 profile image
David Wickes

GUI's can be great. CLI programs can be terrible. The one actual benefit of CLI's seems to me to be the ability to craft a programming environment yourself, hopefully composing tools together to get your work done. But that's a skill that takes time to see benefits.

At work we recently discussed this Quora piece about whether 'dark mode' (white text on black background) is better for your eyes.

It's not. Years of research has shown that it's not. Yet many of us persist in using a black terminal screen (including me) and judging people who don't.

And I think this is a lot of what goes on in the debate about these tools. It's not the actual utility that's being compared. It's usually whether it looks 'cool' and a bit like Hackers Mr. Robot. We'll all say it's because it's more efficient, but it's more likely because we like it.

Software development: still the newest sector of the fashion industry.

rhymes profile image

I tried macOS dark mode, I switched back to the default lighter mode. It was terrible.

Somehow I still can't switch to a lighter theme for the terminal and vs code.

I'll give it a try and stick at it for a while

gypsydave5 profile image
David Wickes

I've not given it a try yet - spent so damn long settling on a dark theme that I'm reluctant to open that can of worms again.

Thread Thread
rhymes profile image

Ahahah we're creatures of habit

shalvah profile image

Haha. I'm glad I switched to dark themes before I got exposed to the wider dev community. Dark themes are better for my eyes. Bright lights and screens tire them out easily.

nepeckman profile image

I hope we can reduce the amount of gatekeeping in the developer community in general. Part of the beauty of programming is that the barrier to entry is low (compared to a lot of other STEM fields), but some people feel the need to construct artificial barriers.

ben profile image
Ben Halpern Author

Yes, absolutely.

quii profile image
Chris James

I am generally a CLI person but that's mainly out of habit and familiarity more than anything

I find it interesting how people go on and on and about how more "efficient" one can be with git for example on the command line compared to a GUI

Software development isn't a race.

What's the difference between someone who can commit some new code and push it in the CLI in ~2 seconds vs a GUI user in ~10 seconds. Nothing, who cares?

There's much bigger fish to fry.

alainvanhout profile image
Alain Van Hout

There also the difference between 'feeling efficient' and 'being efficient'. With the command line, you can fire of lots of commands in quick succession. For a decent GUI, the same required click-click-click, done. Though, as you say, efficiency in infrequent tasks is mostly irrelevant.

rhymes profile image

Definitely, also git has a terrible UI on the command line that we all use aliases anyway so... +1 for GUIs ✌🏾

biros profile image
Boris Jamot ✊ /

What people should know about GUIs is that, at best, they provide the same features as the CLI version. I mean, you will always lose something by using the GUI version of any app.

But that's not their worst limitation.

As @gypsydave5 brilliantly described in his post about the Unix way, you also lose the inter-operability of Unix. I mean, you can't pipe your app to another app if you're in a GUI. You're inside a kind of box where all you can do is only what the developers of the app wanted to put in it.

But if it suits your needs, who cares?

phallstrom profile image
Philip Hallstrom

Two random comments...

  • I'm a long time (25 year) VIM user. Sublime/VSCode/RubyMine/Jetbrains all terrify me. I'm amazed at the people that are productive in them and sometimes a bit envious :)

  • I used to work with a designer that used a stylus/tablet. He never used a single keyboard short cut. Need to copy something he'd go to the menu. Need to paste, back to the menu. Keep in mind this was in Photoshop. It was so aggravating to watch and yet he was just as productive and fast as the other designers and one of the best I've worked with.

jonchiou profile image
Jonathan Chiou • Edited

Great post!

I think in a profession where impostor syndrome can run rampant, being overzealous and participating in/subjected to holy wars over tools/workflows/etc. is, unfortunately, a major byproduct of that condition; people are always going to try and find some form of validation that they aren't a total moron, especially in this industry, and so if you are a vim user and buy into it being THE text editor that REAL PROGRAMMERS use, then anyone who uses anything else is challenging that belief system that you've invested in as a way to prove your worth (both to yourself and others).

This is also compounded by the fact that the amount of stuff to "know" about programming is increasing at an exponential rate; it's no longer sufficient to merely know a language, you also need to be familiar with associated frameworks, different IDEs, etc.

asparallel profile image
AsParallel • Edited

I don't generally shame people for being gui-based, but I do encourage them to learn terminal-centric tools. If you don't, the second you need to access a server without a desktop environment, you're kind of sunk. For me, that's every server.

I'll also admit that I know very few people who are well versed in terminal usage, and are not equally capable with IDEs and common gui tools. When hiring, I expect to see both.

dance2die profile image
Sung M. Kim

That was a great thread with all the contexts provided, Ben.

This post came about at a funny time as I was looking at this GUI editor for designing GraphQL schema.

I am not used to GraphQL at all so was looking for easy way to get started with GraphQL schema design.

for people who don't want to invest the time and effort in trying to find out how something really works

It's not that I don't want to invest time & effort, but I want to get started to s**k a bit less.

I believe GUI tools help you visualize the flow your tools and would help when you want to get your hands dirty.

So I consider GUI a valuable tool.

I don't take an extreme stance that GUI is better or CLI is better. I'd just stick with whatever works the best at the current situation.

rrampage profile image
Raunak Ramakrishnan

At the end of the day, GUIs and CLIs are just that - interfaces to accomplish your tasks. I'll use the best tool for the job. A lot of people hate on GUIs but there are many poorly designed CLIs as well.

For a beginner, GUIs can be better mainly for 2 reasons:

  • discoverability - GUIs show possible tasks through menus. Many also come with a useful Help menu. Beginners are unaware of many possible use-cases of a tool. Getting help in the command-line is non-obvious to beginners.
  • familiarity - Familiarity with existing software you may have used e.g browsers, file managers, Word/Excel etc. This makes GUIs less off-putting to beginners who may otherwise be daunted by the learn curve.

As people in this thread have mentioned, power-users like CLIs because of the scope for automation and composability.

A problem with GUIs is the fear of a software update removing/re-organizing your familiar menu/sub-menus or even worse, some wholesale design change like those Material Redesigns which seem to change the UI/UX just for the heck of it.

txai profile image
Txai • Edited

That's fully related to what Kim wrote about some days ago

If you find some tool will increase someone's productivity, then tell them your reasons, but be respectful. Everyone works in a different manner, so what is better for you is not necessarily better to everyone

ioiiooio profile image

Yup, the "GUIs are for people who don't want to invest the time and effort in trying to find out how something really works." attitude makes my eyes roll. Just because I don't have to send emails like:

gmail send --email message:who the hell would want to send emails like this

Doesn't mean I don't understand how emails work or how to use them. We developed GUIs in, like, the 1970s for a reason? Perhaps the world of programming needs to catch up a bit.

thebadgateway profile image
Will F

I use Jupyter Notebook and gedit when I develop and test. This is partly a matter of convenience in that didn’t grow up using the tty; I grew up using GUIs. Another good part of GUIs is that they lend themselves well to using more tools than just a keyboard, like a mouse.

I find myself using the command line when a piece of software on our Unix cluster needs single (e.g. vi), or systematic (e.g. sed) fixes, and I suspect it’d be faster than scp-ing the file to my machine for editing.

That said, I do like the idea of getting everybody familiar with the tty and the spirit of Unix-likeness. Some of my favorite programs I’ve written are little shell scripts that free up hours 🙂🙂🙂

brpaz profile image
Bruno Paz • Edited

Great article. Unfortunately this kind of shaming happens a lot in our industry, regarding many aspects like tools, programming languages, methodologies etc. "You are not a real developer, if you do something different than what I consider to be the best way"!

And some people get really to the extreme defending "their way". Not everything is a boolean value. There are various ways of doing the same thing and many times, doesnt mean one way is better than another. just different and people need to start understanding that.

Regarding the topic gui vs cli, I use both depending on the context.

For example Git I only like to use cli unless for merge conflicts.

For coding I like to use a decent editor with autocomplete and all the goodies. I use both Jetbrains IDEs and VSCode. Still I always have the "Integrated Terminal" open all the time. Things like running NPM or Docker commands, while they can be run directly from most IDEs, It feels more natural to me to run them directly in the terminal.

I can use vim if needed. Just not with the same level of productivity.

I also have troubles memorizing keyboard shortcuts. It amazes me people who use keyboard shortcuts for everything. The same with code snippets aliases. I can´t handle 3 letter acronyms, like rrc for "reactReduxComponent" in VSCode React snippets. I would name something like "react:redux-component" and have the help of autocomplete.

Everyone is different and have their way of working. What matters is what works for you!

austinhardaway profile image
Austin Hardaway • Edited

While probably not applicable to all cases, I had a mentor die on the git-cli only hill. His argument, which I find persuasive is that all git gui implementations are inherently opinionated. Which operations are hidden in menus vs. front and center, does it make suggestions, etc.

Git from the command line however puts every command at your finger tips, and you can be assured that operations which fail do so because that can't be done and not because they shouldn't be.

This is certainly a specific case. I subscribe to the "right tool for the job" sentiment but I think in this case the right tool is the CLI variant

shalvah profile image

all git gui implementations are inherently opinionated.

All <insert language here> frameworks are inherently opinionated. Hence you should always use the language "raw". 🙂

vinceramces profile image
Vince Ramces Oliveros

GUI is for People who use trackpad/mouse and keyboard while CLI users are all keyboards.

When Figma/Adobe XD/Photoshop/Illustrator used CLI for the first time. trying to find the navigation bar/Side bar, Cmd+C(Ctrl+C) as cancel(terminate). Right Click as Paste instead of Ctrl+V.

I like to be more of hybrid than choosing a side. I am learning it and at the same time can cope up with someone who has experience in both GUI and CLI.


nathanheffley profile image
Nathan Heffley

I know a guy who doesn't use a mouse for any of his IDEs. He set up keyboard shortcuts for all the actions he needs and uses those to navigate files and do whatever he wants. It's what finally got him to move out of VIM 😄

perttisoomann profile image
Pert Soomann

There's definitely a bit "we did it hard and proper way 10 years ago, so that's how we do things now".

When talking specifically about git, check out Sourcetree. They do break the damn thing every now and then with releases, but it's brilliant tool for managing git.

diegomgar profile image
Dieg Oto

I am very confident with my terminal always open, i have trained that way a lot, i supose this is because i have worked so much with command line remote servers.
Most of my partners use GUIs, i have always suposed that this is about the tech path that every one decides to walk through, and in a team, you need both types.
So no shame :)

kspeakman profile image
Kasey Speakman • Edited

I know that one of my other devs cringes when he sees me manipulating code. Because he knows a lot more of the shortcuts in Visual Studio to manipulate things. So he's thinking "he could move that line up more quickly if he hit alt-up-arrow." But for me, I'm thinking "moving a line via cutting and pasting works in every editor i have ever encountered."

I don't really get deep tool knowledge and customization (either GUI or CLI). I follow the 80/20 rule there. I'm willing to invest a little for a large gain. But it is usually not worth the effort to get things "just so". And in fact, it will only serve to make pairing more frustrating with others who don't have their setup identical to my "perfect" one.

As far as GUI vs CLI, I did Windows admin for years (before PowerShell) and then Linux admin for years. They are both means to an end -- providing a working service. The programmer in me likes the script-ability of linux, but it requires a pretty deep knowledge investment by the time you integrate all the little bits and pieces together. Trade-offs. Preferences. Nothing to champion as best.

annarankin profile image
Anna Rankin

As someone who used to teach folks how to use git with only the command line, I just taught another person to use it via the Github Desktop app... it's so so so much better than it was in the past, and it's so much nicer for someone with less CLI experience to grasp the concepts and not get caught up in the syntax.

As someone who's already used to using git from the command line, I don't see myself switching — but it was a wonderful teaching tool, and I'm sure a great part of the development workflow for some folks.

Totally agree - no more GUI shame!

dougaws profile image

I write dev docs; here are some tools that I use regularly (the * are command-line; the + are GUI), in no particular order:

  • git: I wrote my own "cheat sheet"
  • emacs: even after 20+ years using it, I still haven't mastered it
  • cygwin bash for Windows: I have a ton of scripts from over the years
  • RubyMine for Ruby
  • GoLand for Go
  • VS Code for TypeScript project (CDK, check it out)
  • vi for quick edits
  • Oxygen for XML-based doc files, although I often drop down into text mode
  • PyCharm for Python

I still haven't found a great editor for RST files. I've tried Atom, Sublime, etc., but often just go back to emacs, although you have to be careful with tabs versus spaces. I usually just run a cygwin script that uses expand, especially for RST files as the Python-ish format can get hosed results if you screw that up.

stefandorresteijn profile image
Stefan Dorresteijn

It can be painful, but if you see someone doing something "wrong", as you perceive it to be, being an asshole about it isn't helping anyone.

This is true for everything in life no? Shouldn't just apply to developers. If we can all get off our high horses and accept that we might be used to different tools than our fellow devs, we might find that they have valuable insights too!

carlosaabud profile image
Carlos • Edited

I think this is related to each individual and certain trends related to each “group” of people/users. I guess theres not much fun to it If everbody did things the same way; no room for feedback. I agree on the fact of not being an asshole at pointing things out.

Great post!

wolfhoundjesse profile image
Jesse M. Holmes

I am deep in CLI hell, and I’m loving it. Developing from a windows machine is new to me, and it’s been a blast trying to get things working together.

I created “profiles” for Visual Studio Code and aliased them in git-bash via cmder, because I’ve ended up with 50 extensions spanning across C#, F#, Markdown, TypeScript, etc. I even made one for Mermaid because I’ve been tinkering with that repository a bit.
Each one of these profiles has an integrated terminal, e.g., Anaconda for Python.

In the process I’ve duplicated some things (aliases mostly), let some things go (oh-my-zsh on Ubuntu, because WSL still crawwwlllls along when any I/O is involved), and discovered that the PATH environment variable has a character limit.

Meanwhile, some commands are different on MacOS (looking at you, Conda), and I need to know those, too, to support other members of my team.

I can’t tell you how many times a day I try to use grep instead of findstr or dir instead of ls.

Still, in all the chaos, Git is the one tool I have that works almost anywhere, and yet I find myself using the GUI on VS Code because it’s beauiful and loaded with extensions.

Clearly, you really can have it both ways and move throughout your day without shaming anyone.

nicpolhamus profile image
Nicolas Polhamus

I completely agree with you. Live and let live.
I personally tend to be more of a hybrid user, I'll mainly use GUIs and then go to cli for specific things. However, I do have a thing for text UIs. I love a good text based UI, they're so wonderfully weird.

kevin0311 profile image

People who decide to dog on others for using a GUI (or whatever) continually confuse me. It seems to me that they are assuming they know what a person is trying to accomplish and what the person needs to get it done. A person isn't losing out on anything by using the GUI version of an app if it provides what they need, right? It seems really to be a case of some people equating their way with the right way. That doesn't strike me personally as a very rational worldview -- that may be why you see discussions on this subject deteriorate so quickly into useless name calling and tweet wars, etc.

I suppose you can analyze it all day long but it seems to me if we could all try and worry about our own stuff, what works for us, and mind our own business it would go a long way towards offering us all a bit more piece of mind. And in the event someone else's choice has caused an actual problem, well, coming at them with shaming and insults is not the way to fix it. But it can sure cause you all kinds of new problems.

shalvah profile image

Thank you very much for this, Ben. In my early years as a developer, I was happy using my tools (mostly GUI). Then I got exposed to the larger community, and for a long time, I felt like a fraud because everyone kept saying "use the CLI!" (and they keep sharing cool aliases and workflows etc 😭)

Eventually, I learnt that productivity isn't by following a specific set of rules, but discovering what works best for you. And I've made my peace. I'm okay with dropping into consoles on servers, for automation and where no good GUIs are available. But for most things, GUIs work just fine for me.

burdettelamar profile image
Burdette Lamar

I've found that a GUI benefits new or casual users, while the CLI (depending on its robustness) may help heavy-duty users more.

I've also found that it's good to build both, because it keeps the business logic out of both, and in the shared underlying code where it belongs.

arximughal profile image
Muhammad Arslan Aslam

The post and the comments are really good. And there's certainly nothing wrong with using GUIs.

I can say that I'm pretty comfortable with the Git command-line interface and I absolutely love it. But I always have GitKraken open in the background. ALL-THE-TIME. I use it to visually see the timeline, read commit messages, check logs and explore commits.