On GUI-shaming and a mountain of hot takes

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

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.

Vim won't make you a more productive developer

Mac Siri ・ Sep 5 '18

#healthydebate #vim #editors #productivity

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:

How to Improve Your Development Experience

Nick Karnik ・ Sep 22 '18

#beginners #career #development #productivity

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 ❤️

Comments

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

[Michael 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.

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

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

[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]

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

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

[rhymes]

Ahahah we're creatures of habit

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

[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]

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

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

[Ben Halpern]

Yes, absolutely.

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

[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]

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

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

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

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

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

[Jonathan Chiou]

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.