DEV Community

Ben Halpern
Ben Halpern

Posted on

 

On GUI-shaming and a mountain of hot takes

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.

</brain-dump>

Happy coding ❀️

Top comments (49)

Collapse
 
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.

Collapse
 
ben profile image
Ben Halpern

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.

Collapse
 
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.

Collapse
 
lscarneiro profile image
Luiz 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.

Collapse
 
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.

Collapse
 
asparallel profile image
AsParallel

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

Collapse
 
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.

Collapse
 
rhymes profile image
rhymes

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

Collapse
 
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
rhymes

Ahahah we're creatures of habit

Collapse
 
shalvah profile image
Shalvah

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.

Collapse
 
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.

Collapse
 
rhymes profile image
rhymes

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

This

Collapse
 
nepeckman profile image
nepeckman

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.

Collapse
 
ben profile image
Ben Halpern

Yes, absolutely.

Collapse
 
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.

Collapse
 
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.

Collapse
 
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.

Collapse
 
rhymes profile image
rhymes

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

Collapse
 
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?

Collapse
 
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.

Collapse
 
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.

Collapse
 
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.

Collapse
 
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.

Collapse
 
ioiiooio profile image
IOIIOOIO • Edited

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 recipient:a@a.com 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.

Collapse
 
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 πŸ™‚πŸ™‚πŸ™‚

Collapse
 
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.

Basically.

Collapse
 
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 πŸ˜„

Collapse
 
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.

Some comments may only be visible to logged-in visitors. Sign in to view all comments.

18 Useful Github Repositories Every Developer Should Bookmark

18 Useful GitHub repositories every developer should bookmark: everything from learning resources and roadmaps to best practices, system designs, and tools.