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.
Roo@andrew_lowDon't _____-shame period. We need more diversity in programming if we are going to have any chance of making software less bad twitter.com/bendhalpern/st…01:30 AM - 29 Nov 2018Ben Halpern 🤗 @bendhalpernNo matter how much you love the CLI, don't GUI-shame. Lots of perfectly amazing programmers like working with GUIs, and it's perfectly fine. There's some weird gatekeeping tendencies centered around the command line. #DevDiscuss
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.
leeand00@bendhalpern I've seen few good GUIs; also when you really need to get something done, GUIs are so much more complicated and harder to automate. GUIs are for people who don't want to invest the time and effort in trying to find out how something really works.16:56 PM - 28 Nov 2018
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.
Ben Lesh 🧢🏋️♂️💻🎨@bendhalpern 100% agree... But if you're a mentor or senior/lead, it's worth learning the command line for things like git, because you're going to be on other people's machines and they may use different GUI tools or not have your favorite one installed.02:36 AM - 28 Nov 2018
I agree. This is good useful advice. It's a good pitch for learning CLIs in general.
JMS@jessmadeline@bendhalpern I'm surprised at this attitude. I've stuck with CLI as that's what I was first taught and always found GUIs intimidating glancing at colleagues screens. I put myself down for NOT being comfortable with a GUI.20:56 PM - 28 Nov 2018
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.
Sean Steimer@shsteimer@bendhalpern @tkeeney My guideline as a tech lead is that you can use any tools you like, as long as they support a common sense wf to get things done. But if you need my help doing something, I’m only supporting the toolset I know, so you may be on your own for certain things.04:42 AM - 28 Nov 2018
This is a reasonable approach, if approached reasonably. (This is how I talk sometimes. Yikes.)
Stéphane Bjørne@stebjoerne@bendhalpern As an avid user of the CLI, what I experience when I see others using a GUI is a little pain: it is so slow and for me complicated that I don't understand how people feel comfortable using them. Then I remember that everyone has its own preferences, so whatever floats your boat17:11 PM - 28 Nov 2018
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 ・ 1 min read
Be like Mac.
Hyperion ⛓@ygghuur@bendhalpern 100%. I love GitHub Desktop.13:08 PM - 28 Nov 2018
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.
Billy Griffin@billygriffin22@ygghuur @bendhalpern That's so wonderful to hear! If you have any feedback or areas of confusion/frustrating, I'm on the Desktop team so please feel free to reach out. 😀01:51 AM - 29 Nov 2018
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.
Rebecca Conley@bendhalpern Was just talking to some students at @MomentumRDU about this today. I'm glad my current manager, who has more experience than I, encourages the use of GUI tools. There's an implied value judgement about visual expression and graphics with this kind of gatekeeping.03:44 AM - 28 Nov 2018
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.
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 ・ 5 min read
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 ❤️
Top comments (49)
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.
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.
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.
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.
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.
Try setting your merge editor to vscode in git config. It's significantly more full featured than tortoise.
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
HackersMr. 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.
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
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.
Ahahah we're creatures of habit
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.
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.
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.
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.
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.
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.
Definitely, also git has a terrible UI on the command line that we all use aliases anyway so... +1 for GUIs ✌🏾
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?
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:
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.
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.
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.
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.
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.
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:firstname.lastname@example.org 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.
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 🙂🙂🙂
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.
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 😄
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.