The Changelog: Software Development, Open Source - All things text mode (Interview)

Episode Date: April 4, 2019

We’re talking all things text mode with Lucas da Costa — we logged his post "How I'm still not using GUIs in 2019" a guide focused on making the terminal your IDE. We talked through his Terminal starter pack which includes: neovim, tmux, iterm2, and zsh by way of oh-my-zsh, his rules for learning vim, the awesomeness of CLI’s, and the pros and cons of graphical and plain text editors.

Bandwidth for ChangeLog is provided by Fastly. Learn more at Fastly.com. We move fast and fix things here at ChangeLog because of Rollbar. Check them out at Rollbar.com. And we're hosted on Linode cloud servers. Head to Linode.com slash ChangeLog. This episode is brought to you by Linode, our cloud server of choice. And we're excited to share the recently launched dedicated CPU instances. If you have build boxes, CI, CD, video encoding,

machine learning, game servers, databases, data mining, or application servers that need to be full duty, 100% CPU all day, every day, then check out Linode's dedicated CPU instances. These instances are fully dedicated and shared with no one else. So there's no CPU steal or competing for these resources with other Linodes. Pricing is very competitive and starts out at 30 bucks a month. Learn more and get started at linode.com slash changelog. Again, linode.com slash changelog. All right, Welcome back, everyone. This is the ChangeLog, a podcast featuring the hackers, the leaders, and the innovators of software development. I'm Adam Stachowiak,

editor-in-chief here at ChangeLog. Today, we're talking all things text mode with Lucas De Acosta. We logged his post, How I'm Still Not Using GUIs in 2019. It's a guide focused on making the terminal your IDE. And we talked through his terminal startup pack, which includes NeoVim, Tmux, iTerm2, and ZSH by way of OhMyZSH, his rules for learning Vim, the awesomeness of CLIs, and the pros and cons of graphical and plain text editors. So Lucas, late in March, we logged your blog post how i'm still not using guis in 2019 and in that post you said guis or bloatware terminal rules this is a guide to the terminal i'm gonna find kind of interesting about you not only about this blog post of course that kind of

gives this full summary of how to use the terminal as an, but the fact that you have the right command, the colon W command tattooed on the back of your ankle. That's super cool. Yeah, I remember I've done that. And last time I've been to San Francisco, it's actually my first statue. After that, I've got 22, but like that one is the one I like the most. So it was like the first time I was traveling to San Francisco. So I think it was like the proper place. And at the time, I've been using Vim for, I think, two years, three years maybe.

And I was just like really passionate. I just couldn't stop like, you know, talking about it. And, you know, every day I was finding out new things. And it's kind of like Vim is really interesting because the more I learn, the more I feel like I don't know anything. You know, it's one of those things. So, yeah, it's quite interesting. It's like such an amazing piece of software. There's so many things.

It's quite nice. I quite like it. Yeah. The interesting thing about this tattoo is that it seems like, at least based on the picture, that it's on the back of your heel. Is that correct? exactly so that means that as you're walking away is it like a a sign to the person behind you reading this or is it just like by happenstance that you put it on the back of your heel actually uh i put it there because i think it was the less faithful place it was also visible enough uh but uh is it the ankle or the heel?

The ankle. Actually, no one ever talked to me about the tattoo before I ever said anything. I remember I was walking around on, I think it was Fluentcom. I was

expecting someone to say something about the tattoo but actually I think no one noticed which is quite disappointing but it's fine I guess. So Lucas, there's a guy that lives here in Omaha. He has a big mustache, like one of those Monopoly man mustache, you know, like the big, you could like twirl it, you know. And I see him at the deli sometimes

and on the side of it he's like a fix-it guy or a painter I can't recall exactly what his business is but on the side of his his business truck or his minivan or whatever it is it you know it's got the mustache and he's worked into his name and his brand and so I was talking about the mustache I said you there's no way he's had it his whole life now. He's in his 50s. There's just no way he could get rid of that mustache. He's stuck with it. He's worked it into his... It's who he is.

I'm just curious if you feel like you can't quit Vim now. You're stuck with it for life because you're the guy with colon W on your ankle. Yeah, I'm definitely stuck with that for life. I've thought about trying Emacs, I gotta say that, but, you know, it's just,

it's just not who I am. It's too late, it's too late for you. Yeah, it's too late, it's too late, yeah, it's too late. Well, what began your love story with this, with this text editor? So many people love Vim, and we have a hashtag Vim party channel in our Slack team, which was a play on JS party. I was like, we should have a Vim. We have a hashtag Vim Party channel in our Slack team,

which was a play on JS Party. I was like, we should have a Vim Party, because so many of the people on the JS Party podcast are Vim users, and people tend to love or hate it. There's learning curves. Some people never get over that learning curve. There's jokes about, you know, Vim, why can't I quit you? We've made plenty of those

jokes over the years, you know, on Twitter. My favorite was the Singularity conversation. I think you said there's people out there trying to quit Vim as we speak, I believe. I'm sure you said that. Yeah, so I'm always joking about that. And I think everybody, it's a joke that's well used, maybe overused at this point,

but I'm always one to beat a dead horse. That being said, why did you fall in love with Vim? This is obviously core to your idea of doing everything in the terminal, not using GUIs. Vim is a core piece of that, NeoVim specifically. So tell us how you fell in love with it and what you like about it so much that you're like, hey, I'm going to get this tattooed on my ankle. It's been a few years now. I remember when I started, to be honest, I've seen a friend of mine using it and it looked so cool. And he was like super fast with it. So at the beginning it was more like I was more impressed

than, you know, I actually, it was not as if I made an informed decision. I was just like impressed by how things were happening. So I remember we're like sitting next to each other on college and, you know know he was using Vim and I was like hey like what are you doing how do you do things so fast and then he showed me his dot files and you know he explained like me um like he explained how the the whole Vim code works you know um and yeah so then I just started, you know, trying out all my free time because like, uh, at the time I was doing an internship. Um, and I, like if I had used them like on doing work and stuff, um, I like I just kept trying. And in the beginning, I got to say it was very frustrating. But after a month, I was just so much faster. And, you know, my workflow got so much more comfortable that I just couldn't quit.

And now, like, now that I have, you know, now that I started using, like, CLI tools more often. I just like all I know how to do, you know, like all my workflow revolves around, you know, CLI tools. I mean, I tried some, you know, IDEs and stuff. It just is not the same thing, even with remote. I don't know. It's just not the same thing yeah where are you coming from in terms

of a gooey or an ide uh when i started out in uh in college we were using eclipse so i remember like that that was all right at the time but one of the things i struggled the most and i i even talk about this in the post is that uh especially for people that are starting out, I think it's hard to figure out what's the limit of the IDE. You know, like, where does the IDE stop and where does the language toolchain start? So I think it gets a bit confusing for people, especially people that are new. Like, what are the things that are related to their development environment? And what are the things related to the toolchain they're using. So that, I think, made things harder to understand.

So once I moved to Vim and I just started using my terminal all the time, I feel like I know what my machine is doing. It's not as if I was handling that to an ID. I'm not just pressing buttons and expecting things to happen and not really knowing what's going on in the background. It's like I feel like I'm in full control, and if anything goes wrong, I know what the CLI is telling me, what the CLI 2 is telling me, what the terminal is telling me,

because you get used to the terminology you get used to like um how things fail instead of just like cryptic error messages or you know like just uh pop-ups or errors being hidden or anything like that so it seems like there when you when you think about am i going to use the terminal or really thinking if i'm going to base my workflow around the keyboard or around a mouse, the arguments around the keyboard in a terminal versus GUIs, which usually require a mouse or another input device beyond just a keyboard, the factors are speed, somewhat context switching, but I think it's speed of moving your hand off or on the keyboard to the mouse, which is slower. Once you're there, then then it's fast but that transition back and forth slows you down and then

also the idea of customizability or malleability I think a lot of the modern text editors are catching up in the malleability category if you look at just the way you can trick out bs code or sublime text uh to the hilt at this point and so many things are built in or not built in but available to be added removed and customized um but if you had to think about what was the most important thing you seem to be focusing a little bit on the speed because you say you feel like you're a little bit closer to the metal so to speak maybe there's an analogy with you know driving a car enthusiast like like a manual transmission regular people like an automatic transmission is the speed really key for you i don't think actually the speed is the key for me uh i think of course it's more comfortable to use a keyboard

all the time but actually most of the time i don't think we're writing code, right? I think most of the time we're just like reading, we're thinking. And what I really feel that makes a huge difference for me is that I don't feel like there's anything on my way when I'm transposing thoughts to code, you know, just it's so much faster and it's so automatic now. Also, I can switch between like environments like often when I pair with coworkers, I can just, you know, like open a terminal window, spin up in and I'm fine without plugins, without anything. So I'm like good to go everywhere. I don't need to install anything. Also, like even if I need to to configurations are a lot more portable I think there are many

more advantages rather than just being fast I mean being fast is cool right I mean when you when I'm when I'm doing a talk and I'm doing live coding you know if I open Vim I know that the subject of the questions are going to be about Vim like at least 50%

of them and the other 50% of them are live coding. Yeah, it's just like, it's fun, but I don't think it's the main reason why I use Vim. It's probably what got me started, but not what keeps me going in it. It seems like the limitations of, as you've said in your post too, the limitations of a GUI being bloatware for one or just containing

features that you don't really need, you in particular, maybe even all users at large, for the most part, this is a, you know, getting past that and sort of back to the analogy of having access to bare metal makes a lot of sense. But one thing you mentioned was how you persisted through learning Vim, which is for me, that's been my hangup personally. Like I still use VS code. I'm a previous sublime text user. I, uh, know many of the Vim commands and, you know, I'm an occasional coder, not an everyday coder. So I don't feel like I need to learn this today and you know there's part of me that has regret like man I really wish I would have persisted like you did you know on a

side project or found some sort of way through because some somehow some some way along the way you know as you said you'd fall in love with the vim way of things versus a gooey way and you couldn't go back can you talk about that persistence and maybe some of the things you did to persist? What were the things that made you get over these learning hurdles of Vim? I think the learning curve is easy, it's cheap, but I think when you use a tool for a while,

like you use an IDE or whatever your text editor is, I think the more you use it, the faster your own smaller tasks start to matter more. So I think the learning curve is indeed worth it. Because if you use an IDE for a long time, even though you learn some commands, you're not forced to learn key bindings, to learn shortcodes or anything. You just keep clicking around. And many other programs, they don't even give you that great quantity of key bindings.

So I think that for what us engineers do, I think it's a lot easier to use CLI because since you repeat tasks a lot, it's a lot easier for you to memorize a few words and just be accurate when communicating to the machine than actually keep searching for buttons or anything like that. But my experience learning it was indeed very, very frustrating in the beginning, especially because I was using many plugins. I don't think I started it right. I think it's just, like, pleasurable, you know.

It's something I still enjoy, just sitting down and, like, configuring things, you know, like, going through plugins, seeing what other people are using and like seeing if I can do something faster. Cause I'm the kind of person that gets easily annoyed by tests that I have to perform to like too often. I I'd say I strive to be lazy. That's a, that's a phrase I've heard once. And I think it's, it's what motivates me to keep going

keep using Vim because if I have to do something more than once or if something feels boring I'll just try to automate it or try to find an easier way of doing it and I think that's a great attitude to have when you're learning Vim just strive to be lazy

and try to find easier ways of doing things I think that's the key idea. I'm in a little bit of a different situation because I might be the only person who's persevered, not the only, but a rare person who's persevered through learning Vim and still doesn't like it that much. Careful. Yeah, I don't dislike it.

Let me tell them. I feel like I've shared this before, but I'll share it again just for the conversation. So my introduction to Vim was by necessity. My teacher in college teaching me C++,

he basically was a Vim diehard, and he said, you're going to use, you're going to SSH into this Unix machine, and you're going to use Vim. And that's what you're going to do. And there's no ifs, ands, or buts about it.

So that's what you're going to do to write your C++ programs., ands, or buts about it. So that's what you're going to do to write your C++ programs. Therefore, I didn't really have a choice. I think if I had choice, in fact, he let us use, it was either Pico or Nano. I think it was actually Pico for the first like two programs.

And then he's like, by the way, Pico is, he specifically said, a text editor in which you should write letters to your grandma, but not write computer programs. So he was very, very opinionated and made us laugh quite a bit. But he's like, don't use Pico to write programs.

I just let you do that. Now you're going to write Vim. And so I learned Vim basically by necessity over that semester. And I didn't really know there was, this is back in like the early 2000s. I didn't even know there was a different world of GUIs and IDEs or any of these things. I just learned, I cut my teeth on Vim. And so I'm very proficient with the editor. That being said, on a daily basis,

and I write software on a day-to-day basis, and I rarely choose Vim as my primary editor. I'll use it on servers. I will use it as a secondary editor. But I almost always prefer and choose a graphical interface. Specifically, I use Sublime Text, but I feel very similar about VS Code. I actually feel like they're faster in many cases for me, and I think it's problematic. I think we should be careful not to conflate the idea of a graphical interface with bloatware.

If we say there's GUIs and there's IDEs, yes, an IDE is a graphical interface, but not all graphical interface is an IDE, right? An IDE is an environment. It's like an all-in-one, similar to like a framework versus a library, right? It's like a framework. And yeah, those are, you know, Visual Studio,

maybe Eclipse. These are things I don't have much experience with, work and yeah i think those are those are you know visual studio uh maybe eclipse these are things i don't have much experience with but you know uh xcode i have some experience with when you click the button to start it and you got to wait 30 seconds for it to launch because it's bloated in my opinion um but visual studio code vs code sublime text adam text mate um notepad plus plus i don't know what's on the Windows side. These are things that, to me, they feel lean and mean. They don't feel like bloatware. They feel like fast, small, lean programs that I can extend.

And in my current life, by the time I get Vim configured to do all the things that I want out of a text editor, it's slower than, in my case, Sublime Text for many tasks. I think what you said there, too, on the IDE front is pretty important, too. The don't confuse VS Code or Sublime Text, in particular those two, because those are the ones I'm most familiar with, like you are, with, say, Eclipse, which is meant to be

an integrated thing into the language. It's almost something you said, too, Lucas, where you said that you're not really sure where the IDE ends and the language begins, you know, that you sort of have this missing piece. But IDE, just to spell it out for the listeners that may not be aware, is it's an acronym, obviously,

for Integrated Development Environment. So that just means that you're taking this environment, this GUI, and integrating it into a particular platform. It could be a framework. It could be a language in particular. There's ones around Ruby. There's ones around Java.

There's ones around Go and many of them. And there are four good reasons because there are certain special or magic or sugar in a language or in a framework that you want to extend to a GUI to sort of you know speed certain actions up that you repeat a lot the same that you might do with a plugin or you know an alias or something like that so that's where this really comes in I think your point though Jared to not confuse the two is very important, I completely agree with that. I just, I mean, I think even like VS Code is like a great application, sublime as well.

I really don't like IDEs, but like, I think there's still some disadvantages. Of course, everyone has their preferences. Like for me, what motivates, you know, like what motivates me to keep them is that I think I would say that when you're using command line interfaces,

you can just, like things already written for you, it's easy to communicate between programs. As Douglas McElroy has said, if you write programs that work well together and if you use the universal interface, which are just like tech streams, I think it's just so easy to incorporate new things into your flow. Things get so much more flexible. And I think you avoid writing software because if you – I feel like there's also lots of duplication because if you already have tools available

for you to do one thing, if you can use streams and you can combine multiple programs, then I think many times you would avoid writing a plugin. Also, that's how I feel about Vim now. I don't try to make Vim an IDE as I tried in the beginning. I just try to go with the raw thing and try to use the terminal the way it is supposed to

be used, I guess. But of course, I think VS Code is great. I've seen lots of people using it already. And I think that's a very important distinction you made there. I just think that there are still some advantages to using the terminal. Don't get me wrong. I'm a terminal junkie. I'm just speaking specifically of having your primary editor in the terminal. That's pretty much the only thing that I don't do in the terminal. Everything else is. And so I agree with all of the things that you're saying there.

And I've found that Vim fits well in that workflow. So I'll use it as my dollar sign editor in my environment variables so that when I'm going to do a git commit, it will open it in Vim. So I'm not completely on the other side of the fence here. I'm just a person who, when it comes time to day-to-day writing software,

I do enjoy both the speed and uh there's an aesthetic value to a graphical interface that draws me over vim this episode is brought to you by clubhouse. One of the biggest problems software teams face is having clear expectations set in an environment where everyone can come together to focus on what matters most, and that's creating software and products their customers love. The problem is that software out there trying to solve this problem is either too simple and doesn't provide enough structure, or it's too complex and becomes very overwhelming. Clubhouse solves all these problems. It's the first project management platform for software teams that brings everyone together. It's designed from the ground up to be developer first product in its DNA, but also simple and intuitive enough that all teams can enjoy using it. With a fast, intuitive interface, a simple API, and a robust set of integrations,

Clubhouse seamlessly integrates with the tools you use every day and gets out of your way. Learn more and get started at clubhouse.io slash changelog. Our listeners get a bonus two free months after your trial ends. Once again, clubhouse.io slash changelog. So we've been talking about bloatware and I'm trying to define some lines because I think there's some GUIs that are and some that aren't. Lucas, you start off your post saying GUIs are bloatware and you said it before. So this is something you got your thoughts and reasons about.

Expand on that for us and why exactly this is a talking point for you. Yeah, so I think as we were chatting, I think it's important to make this distinction between like GUIs in general and IGEs. Of course, I don't like, I'm not a big fan of GUIs in general. I think they're just not optimal for what we do. I'm not saying like that GUIs are bad, that are inherently bad or anything. You're saying that like due to the nature of the tasks we do, which involves a lot of repetition, which might involve a lot of need to automate things, a lot of need to, you know, integrate programs, you know, combine programs. I think when you use CLI tools, I think you're a lot more flexible when it comes to that.

You know, it's a lot easier to combine programs using streams. You can use many tools to automate what you're doing. It's a lot easier to create scripts. It's a lot easier to extend programs. You don't have to write a plugin. It's just many things are available right out of the

box because people have written great Unix tools. You know, just type them out when you need, like, and just type them out than it is to, you know, be searching around for buttons or, you know, trying to remember,

like, a specific sequence of things you need to do whilst you could have automated all that. So, yeah, I think there are, of course, advantages to using GUIs, but I just think that due to the nature of the things we do, I think it's more productive to use CLI tools also,

like all the information they provide you, you know, all the... It's a lot more, I think, when it comes to how you communicate with the machine, it's also a lot more exact, it's a lot more precise. So I think it's kind of like as if how you communicate with the machine, it's also a lot more exact, it's a lot more precise. So I think it's kind of like as if you were talking with a machine in its own language.

So it's easier for you to understand what it says, and it's easy for you to tell it in a precise way what you want it to do. Another point that you make in your post, which I appreciate and agree with, is that when you invest learning time, because that's really what you're doing when you're learning is you're investing in future you. And when you're investing in command line and terminal Unix-based, POSIX-compliant Unix philosophy tools, these are portable skills that can be moved to a new environment, a new language, the next thing that you're doing.

It could be on a different machine altogether. You can SSH to any Linux box in the world and it's going to have Vim. It's going to have, it'll probably have Pico on there too if you don't want Vim. It's going to have LS, right? It's going to have Tree or,

will it have Tree? Maybe it'll have Tree. Point is, these things are portable whereas on the other side, if you're using an IDE or a graphical interface that is a larger, kind of a monolithic program,

you're really investing in one thing, right? You're not in stocks and bonds. We call this, you know, your portfolio isn't diversified. And so you can't take that, those IDE skills, move them elsewhere and they, and use them. And so I think that's a really big talking point and a reason to invest in CLI. You're also assuming, too, that the visual goes with you, like you'd mentioned in college, Jared, that we do this every day, SSH into a machine, and I'm on DigitalOceanBox or Linode or whatever. There's not actually a monitor there.

There's not some sort of visual. The visual is the terminal. So when you invest in VS Code or a GUI in those cases, then you really can't take that with you from a visual standpoint either, let alone just an installation option. Even if you could install VS Code

on the machine, you can't see its interface via SSH for example. True. Now you can get fancy and mount a dry like an ssh mount and use your local vs code against a remote machine or something like that but point yeah point taken yeah uh yeah that's that's one of the reasons why i don't uh i don't want too many things to my vim configuration you know i try to use it as vanilla as possible it's kind of like this discipline pursuit for less so that I can be

comfortable in any environment. Sometimes when I'm pairing with a coworker or anything, many times I'll just fire up Vim and just use it without its syntax or highlight or anything because I just feel comfortable that way and it's a lot easier for me to write code

anywhere on any device. It's really good, yeah. Would you consider yourself a minimalist or somebody that stri easier for me to, you know, write code anywhere on any device. It's really good, yeah. Would you consider yourself a minimalist or somebody that strives for minimalism, considering you said this discipline pursuit of less? I think the more I do software, the more I strive for less, I think. I think I actually, like, I think less software, yeah, sorry, I got a bit lost.

Yeah. You agree with minimalism, long story short. Yeah. I like what you say, too, in this post, too, around your advice, basically, you know, to to for beginners, at least, is to resist this urge to just use all the plugins possible out there and to sort of like learn it incrementally and then layer on plugins that may be useful to you, you know, as you sort of gain more and more proficiency. Was that when I asked you earlier in segment one, you know, what some of your tactics were to getting past the hurdle. It seems like maybe originally you tried all the plugins and then at some point you gained some wisdom and you said, well, maybe, maybe actually if you're learning Vim for the first time to get over this hurdle, don't try to use all the plugins possible to actually achieve this minimalism we're camping out on here. Yeah, I completely agree. I think, I think there are some plugins that are quite useful when you're starting out,

like NodeTree or, you know, like Contropi or FZF, which is what I use now. You know, just being able to falsify files and, you know, seeing a file tree. I think people are so used to that in, you know, every single text editor or, you know, IDE they use. That's such an ubiquitous feature. I think those are quite useful. they use that, that's such a, it's such a, an ubiquitous feature, feature. I think those, those are quite useful, but many things, I think they can just be done in vanilla. And I think it's just easier and more portable if you just, just vanilla. Let's expand from the Vim conversation and talk about some of the other tools that you're

using. So in this post, you have the terminal starter pack, and it includes Vim or NeoVim in your case, Tmux, iTerm2, and ZSH, and OhMyZSH. And when I read these four things together, I think it's a very nice starter pack. I would say that on the Zen Minimalism side, if I could say the word, and on what's stock on computers that you're going to be using elsewhere, I would actually argue that I'm beating you in this category because iTerm2 isn't on machines by default. CSH sure isn't on a lot of machines by default, whereas Bash would be.

That being said, Tmux isn't, and I'm a rabid Tmux user. So just curious why this is your starter pack and maybe give us the reason why you pick each of these tools and why you like them. Yeah, so I think NeoVim was a natural evolution for when you're using Meme,

I think it's just like you end up getting annoyed by the synchronous task and I think it's just like a natural move since configurations are compatible and everything. I think that also once you've used a couple Term terminal emulators like item 2 or terminator or whatever you use, I think you just like...

It's a natural evolution to go to Tmux, I think. Also, it's very configurable, all the plugins and everything. Also being able to attach and detach sessions. I think Tmux just integrates really nice with everything else that's on a terminal. I think, as you've said, like iTerm2 is not available everywhere. That's true. But to be honest, when I started using it, I wasn't really very proficient with terminals.

So I just started using Item 2. I quite liked it. I used to replace lots of Gmux features, splitting panes and opening tabs. And then I think what got me was how easy it was to configure or how easy it was to import color schemes and all that. And I think it's just like, you know, it's just. Inertia.

So I'll challenge you a little bit on that one because I have a former iTerm2 user and currently terminal.app. I think I accidentally talked Adam into just using the stock terminal on the map. Sure did. Mostly because of how much previously I learned GNU Screen.

So I switched to Tmux probably five years ago but I was a screen user which gives a very similar feature set to Tmux, just a little bit less usable and broader, I should say. I found over time that iTerm2 wasn't actually providing any features that I needed because I do so much with Tmux.

And so Terminal app, you can change the font, you can change the theme, and I don't really use tabs, and so everything's in Tmux with sessions, and I like Tmuxinator. I think I recently wrote about that on Change.com if you want to read that. So curious

if iTerm2 has any killer features that you're still using it, or you're just kind of using it because that's what you learn and that's what you like and you haven't had any reason to stop. Yeah, to be honest, I think iTerm2 is more because of inertia, I'd say, yeah.

I think that's just what I'm used to and I find it so easy to configure the phones, the color scheme and all that. I'm just so used to it and I think from all the things in the stacks, the thing I interact with the most, I think I replaced like all the features I used to use from it by Tmux.

So yeah, I think Tmux just makes my, my workflow so much more organized. You know, if I'm, you know, if I'm writing code and, you know, something urgent happens and I need to, you know, jump in like to do support or anything, I'll just detach a session, create a new session,

or just move to a new tab and just do it very fast. I don't have to think too much about it. So I think Gmux ended up replacing all those features for me, and I just use it more of inertia, I'd say. So would you say that iTerm2 is questionable then for you that Terminal would do most of it? Yeah I'd say it's pretty questionable

I'd say it's more because From the minimalism perspective there's nothing wrong with it, it's a great application Yeah well maybe you just talked me out of it I'm just an install now maybe I don't know actually touch me out of it. I'm just an install now, maybe.

Yeah, no, just I don't know, like, actually yeah, that's a very good point. I use it more. What brought this up for Jared and I was, and this is about two years ago when I said, Jared, you got a new MacBook Pro. Yeah. And, you know, what hacker can resist the question of, so what are you installing on this new machine?

You know, and that's the age-old, you know, great conversation to have so he was talking through certain things is you know what i'm actually going to just use terminal instead of i'm trying to resist he said i believe if i'm recording from before i'm resisting installing i term two uh because just to see if i can get by without it right because terminals already here wanted to try to use this and for these reasons uh you know he's already using tmux and try to use this? And for these reasons, he's already using Tmux and whatnot. And so the next time I got a machine,

I recalled that conversation. And I'm a fan of minimalism. I achieve and aspire to have less. Doesn't mean I always am a minimalistic person. That is my natural state of being, though. So I was like, you know what? I'm going to follow in Jerry's footsteps and just resist iTerm2 and use Terminal. And I haven't looked back since.

That's years now. However... And to be fair to iTerm2, the built-in Terminal app has gotten a lot better in recent years. There was a time where there was a huge disparity between what iTerm2 provided and what the built-in app provided.

It was way better in multiple ways. Most people use it because of the split panes, but like we said, if you have Tmux and you're familiar with that, it solves that problem for you. I think there used to be a bigger difference, and I think at this point, it's less so. But that being said, if I go

through and look at all of iTerm2's features, I can probably find reasons why I'd want to use this. I can probably find reasons to install it, but my new philosophy is, instead of asking why shouldn't I install something, ask why do I need to. If I don't need to, don't do it. That's kind of a

minimalism perspective, I believe. How far can I get on just what's already available to me? When it comes to the command line and Unix-based tools, you can live your life without installing very much. That being said, Lucas, I'm curious if you've ever heard of

Tmuxinator or ever tried it since you're a Tmux fan. Is that something you're familiar with? No, I haven't heard of it actually, Tmuxinator. Yes, I haven't heard of it. It's pretty cool. So if you have a lot of ongoing projects, which a person who does client

work, as well as coding stuff for change.com, I have a lot of little projects going. And it's common to have different Tmux sessions for each of those projects and hop and forth. You detach one, attach another one, and it's all set up and ready to go. Well, Tmuxinator, unfortunately, it's all set up and ready to go right well tmux

simulator unfortunately it's a ruby gem so it has a ruby dependency upon it i love it to be it's like written bash or something but it's basically a way that you can create your own configurations for tmux name them and then define like all the panes and what each command will get run in each pane and you just store them in YAML files in your home directory. And then you can just say, you know, tmux changelog. And it'll just start that whole session for me and save it for me from scratch.

And I can have one of those for each particular thing I'm doing. It's really pretty cool. And anybody who uses tmux, I would suggest at least checking it out because it's a good idea. I think it kind of like fits really well with what i usually do because like i have i have kind of these implicit rules for myself like usually you know when i'm working on a certain project like this first this first pane we always

do this thing you know the second time is always going to be for that thing so it's usually like oh my first you know my first tab runs things and you know just you know keeps a window open for if i in case i need to move files around or anything. And the second one is always Vim and running some tests or anything like that. And I can have these rules for myself. That automates that. I think it

fits really nice with what most people do, actually. Yeah, it's pretty cool. So for Chainsaw.com for instance, the first pane is the server running, and then the second one is a console session open with the whole framework loaded and everything. The third one's the tests running,

and then the fourth one is just a shell. And so I don't have to... I can name them. I don't have to set them up every single time because you do find yourself doing the exact same thing. What would be cool is if you could just have Tmux sessions last persist through reboots,

which I feel like maybe there's some hacks out there that make that work, but it was never really reliable for me. So those detached sessions will persist and live forever until you reboot your machine. And so this is a nice way of just configuring it once per project and not having to worry about

it. Well, most of the procrastination that could happen or would happen would because of all the necessary cadence or ceremony to begin right like that's that's some of the reason why people put off a task is like all the necessary steps you have to do to actually begin the task not just actually achieve the goal so So in this case, if you want to work on a cook bug or just anything really fastly, then if you had to do that ceremony every single time, you'd be less likely to...

To even get started. Yeah, exactly. Or you just find yourself typing the same crap out all the time. As programmers, every time we type the same thing over and over and over again, our brains start thinking, how can I not do this every single time? And know and that's a lot of stuff lucas has done you know what you're sharing here in your setup is really just you solving those problems and um it's one

of those things i think the mindset of a terminal slash uh in terminal editor user versus a IDE user is an IDE user generally is like, just do all the things for me, give me a button, and I just want to push it. I think that's a perfectly viable way of looking at it. But on the other side, it's kind of just the more hacker lifestyle of, no, I'm going to actually, I'm going to create my own environment that's ideal and perfected. And I can smooth over all the little issues. One thing that I've done years ago and I don't even realize anymore, I think about it now

because we're talking about this, is I just started realizing in the command line, every time you change directories into a new folder, what's the first thing you do pretty much? What's the next command? LS, right. I'm in a new directory. It's similar to And what's the first thing you do, pretty much? Like, what's the next command? Yeah, ls, right? Ls, yeah.

Like, I'm in a new directory. You know, it's similar to like, when you're like a text-based adventure, and you're like, I enter a room, and now you're like, okay, tell me what's in the room. You know, I look around the room. Yeah, role perception. Yeah, cd and then ls, pretty much every time.

And even if you didn't want to ls, would it bother you if you did? So probably, I don't know maybe 10 years ago i just overwrote the cd command in my bash dot files to just ls after i cd every single time for me and so now that's just the way it works i change directory it prints it out and that's just the cool stuff that you can do and maybe i'm the only person in the world that likes that that's fine i'm the only person in the world that has it then the cool thing is we've kind of gotten to this sort of blacksmith kind of mentality of say ages of old whenever you know the blacksmith in the town was the one of the most popular persons because they would

be the tool maker and this was just an age where it was common in a practice or a craft to form and create and manipulate your own tooling. And I think that that's kind of maybe even potentially a divide of hacker type, where not so much that you have to fully adopt this, but that you can appreciate your ability to fine-tune your tooling. Like when you mentioned the IDE, Jared, having the button, that's a perfectly viable option. However, you know, the hacker way tends to be,

you know what? I like the button, but I want it to do this, this and this as well. So a GUI may not be the better fit because you're the kind of person or the person is the kind of person using these tools to want to make

and fine tune their own tooling to adapt and be the best practitioner yeah there's a lot of pleasure also like when you when you do something yourself you know like you know exactly like how it works you know uh you know what you need to do in case you need to do any fixes you need like you know exactly what's happening um and i think it's also like very pleasing as you said you know it's just There's absolutely a satisfaction to solving your own little problems. And just being, it feels empowering to just say, you know what, I had this, this bothered me.

It was the smallest little thing. And I came up with a reason, I came up with the idea of why would I just change it? So every time I see the LSs, and from the point that I had that idea to the point that I had it finished, I had to realize that if you override a built-in command in your function, you have to call the built-in.

Literally, the word built-in CD. That was the only part I had to figure out. From the idea to initiate, or what's it called? Finish, right? Start to finish is probably 15 minutes. And it's been serving me like that for 10 years of my life. That feels really good right those 15 minutes was well spent to invest in the future so which i think was one of the main points lucas you were driving home earlier yeah something else you mentioned too

though jerry was was bash and configuring it and hacking it so the last piece on the terminal starter pack is is zsh and maybe the extension of that is Rob Russell's, Robbie Russell's Oh My ZSH, which I'm a fan of personally, but you use a Bash or you're using Bash, Jared, so we're like two to one here. Oh, you got me cornered. Well, Lucas, help us understand

why is ZSH something you reach for since you're a minimalist and Bash, as Jared said before, is on every machine. Yeah, so I think when I started out, I was using Bash. And then I think the thing that drew me to ZSH was the auto-completion. I think that was like the clear thing for me, the clear feature. I think that's what brought me in. Also, all the

glob patterns and all that. And I think just managing configuration with Oh My Zosh is just so easy. Also Zed, it's just... That was kind of like a... But I think the killer feature

was for me the auto-completion. And you can just get auto-completions for everything you use. But here I'm about to say, you know what? If there was Oh My Bash, I might... Because what actually draws me to ZSH is less about ZSH and more just the fact that Oh My ZSH existed and it made it so easy. And I like the easy button there actually isn't oh my bash yeah that's hilarious so for us uh layman over here tell everybody what oh my zsh is i'll just read the the uh description on the repo a delightful community driven with over 1300

contributors framework for managing your zsh configuration so it's it's really about oh my zsh is awesome robbie made this configuration for it you know that was that's what oh my zsh is now to sort of make plugins and this extension to use rails get and have all this configuration a lot easier and that's what oh my zsh is this extension this layering on top of ZSH to make your terminal prettier and things like that. And just change and augment the visualization of your command prompt. That episode was a long time ago, back in 2011. We'll put that one in the show notes. Go back and listen to that.

The old Adam Stack. That's right. And Kenneth Reitz. The OG Adam Stack. That's right. See how Reitz. The OG Adam Stack. That's right. See how that audio sounded back then. So that's what Oh My ZSH is. So Adam, you got brought to ZSH because Oh My ZSH was so cool.

Right. And Lucas, you got brought to it because autocompletion was better than Bash. I'm not sure if that's still the case. I mean, Bash has autocompletion. Maybe it's just not as good as ZSH is. But I'll probably just stick with Bash. Yeah, I think indeed Oh My Zosh makes it a lot

easier to get started with it. The community is just so huge. It's just so easy to find ways of solving your problems. Find help and documentation and everything you need. Yeah, I think Oh My Zosh did really foster the world,

made it a lot easier for people to start using ZSH. This episode is brought to you by our friends at Rollbar. Move fast and fix things like we do here at Changelog. Check them out at rollbar.com slash changelog. Resolve your errors in minutes and deploy with confidence. Catch your errors in your software before your users do. And if you're not using Rollbar yet or you haven't tried it yet, they want to give you $100 to donate to open source via Open Collective. And all you got to do is go to rollbar.com slash changelog, sign up,

integrate Rollbar into your app. And once you do that, they'll give you $100 to donate to open source. Once again, rollbar.com slash changelog. So you talked about the four pillars, you might say, of your setup, NeoVim, Tmux, iTerm2, and ZSH by way of, oh my ZSH, of course. The command line and the terminal is way more than that. And the more of the commands that you know and learn and ingrain into your workflow, the better you are at it. Now, one of the hard parts about the terminal, similar to like an Alexa device, is discoverability isn't the best, right? It's difficult to ask the computer, what are all the things that you can do? Because, well, there aren't buttons to click on which tell you what

they do. So one of the things you have here at the end is other useful programs and things to know in order to get good at the terminal and use it instead of the GUI. So why don't you go ahead and we can talk about a few of these. There's a lot of beloved favorites in there. Curl, of course, at the top of the list. Much beloved around here. Daniel Stemberg, kind of a hero of ours and a frequent guest on the show for Curl and

all he's done there. But I'll teed over to you, Lucas to talk about some of these other commands that you found useful and you integrate into your terminal life. I think, I think these are the ones that, you know, make it easier for you to do everything you do in a,

in a, in a UI. I think those are the things that people do the most. So I think it was, was useful to put them down here so that people know, Hey, these are the things I can use to replace whatever I'm doing right now and maybe do it more efficiently

and in a more flexible manner. So I think JQ is really, really cool, especially because if you're using curl, you're probably going to get JSON back and you want to work with it in a nice way, in a simple way. Also, Streaml simple way. Also, Streamlater, SCD,

I don't know how you guys call it, like SED, S-E-D? That's what I call it, SED. I don't know. Yeah, I quite like SED also since I already use it quite frequently. I got very familiar with regular expressions and

I very rarely need to Google a regular expression because most of the things I do also are simple regular expressions. AG is very useful, especially when navigating a true code when trying to find something. I actually use it through FZF on Vim. So actually my FZF plugin uses AG. And it's really easy to configure. I can just like use configuration to ignore whatever is on my GIF ignore.

So I don't get all those annoying old modules when I'm searching for things. So it makes it really easy to navigate around to find things. AWK, it's like, I always have to do exactly what I need to do. It's like, you know, it's not very verbal. So I think it makes it harder for you to remember things. Like unless it's something very basic, I mean, Googling is required, but it's very useful. R-Sync, you know, I was seeing a talk these days,

and a guy was saying that R-Sync is made of magic, and I couldn't agree more. R-Sync is indeed made of magic. Very useful for me. Why do you say that? It's just like, it's ridiculously fast, and it just works so well. It's ridiculous

simply to use. It's just, you know, just having an incremental file transfer that it's so easy to use. It's just, it's just ridiculous magic.

Also, Grab. Grab is such a great tool. I was reading these days on how I can use a post about why Grab is so fast and it was just

all these things have so much magic into them. It's not just rsync. I think rsync and Grab stand out but I think both rsync and Grab are great tools. Also Make. I think many people overlook Make. I think it's such a great tool for automating

tasks and even though there's this joke around of there only having been one makefile and all their makefiles are copies, like a bit modified of this first makefile, I actually think make is like a great tool. I think it plays really well even with the NPM scripts and all that.

I think sometimes, you know, things like Google foreground are like quite annoying to configure maybe. So I say make this many things really well and it's really simple to use and has been around like for a very long time. So I quite like it as well. So Lucas, for more on make,

stay tuned to an upcoming episode because gare hard lazu are our devops buddy uh who just recently redid changel.com infrastructure for 2019 is coming back on the show if you guys recall a while back we had him on maybe it was 2018 maybe it was 2017 i don't recall our first time deploying chang Change.com as the open source CMS. That was with Ansible and Docker. Well, we've got a brand new setup and Ansible's completely gone, Docker's still

there. You definitely want to find out what we're doing this time, but I'll tell you, Gerhard is like a makefile guru because all of our Ansible scripts have been replaced by one makefile, which is open source in our repo if you don't want to go read it. And this thing has all sorts of interesting features. I never reach for make.

I use it when other people have written makefiles. I wouldn't reach for it myself, but it's awesome to see how much you can do with a makefile. So just a quick plug for that. And I agree, there's definitely a lot of tasks you can automate beyond just building and compiling code. What I love about this list is that it's, as you said, Jared, with Alexa, which I think is actually a great analogy, is discoverability. The way that you discover these kinds of things is by somebody else going down the path and doing a retrospective and sharing their learnings, right? Because you can assume imposter syndrome or, you know, you don't know as much as somebody

else, but meanwhile, you're a few steps ahead of somebody else and you can always share back a little bit. And this list alone is going to be helpful for, you know, a future or up and coming programmer that is like, I never really knew or how to use make. And now, you know, now they've got this got this list to go off of and some experience. I think Make is definitely amazing. I even joke in one of my talks that we use Make in lots of projects and we even use Make in Chai

because we're vintage and we don't like Gulp, Grunt or In-Term Scripts or any of that just because it works and it's been around for such a long time and, you know, it's just so well documented and so easy to find material about. It's just amazing. I quite like make. Not modern, Jared. Vintage. I like that. Minimalist. There's a lot of things we can call make,

but I don't think we can call it minimalist, right? Yeah, vintage is a word I like I mean uh coming from someone that lives in this London I think that's the right word to use love it I also give my plus one to most of these I think rsync I would be embarrassed to tell you how many things I'm still you know deploying or or backing up with rsync on different machines around the world. Such a useful tool. So AG, you talked about AG. You didn't pause there very much. This is a search tool similar to ACK.

So there's been this progression of search tools. GREP, which is built in on all Linuxes, most Unixes, is an awesome tool. ACK is a replacement for GREP. I remember with a great website, betterthengrep.com. AG, A-G, is called the Silver Searcher. It's just like ACK,

only it's focused on speed. I think it's written in POSIS-compliant C code. So is this AG, the AG, the Silver Searcher, do you use this only inside of Vim by way of a plugin, or is this also just, you just use it from the command

line tool when you're just searching a code directory or for, do you use it in place of grep or do you also use grep in different contexts? I also use grep. I use AG mostly inside of FZF indeed, but I'll

also use it when I'm navigating around. Sometimes I'll use git grep if I'm not in Vim because I want to ignore whatever's on GitIgnore and just like see what I'm dealing with in Git. But yeah. So when would be a time that you'd reach for GitGrap versus AG from the command line? Is it when you're searching for something specific?

Or I just don't understand why one would be used over the other. So you mean, why would I use AG instead of GitGrap? Or vice versa from the command line. Like, why doesn't AG fulfill all your needs, would be the question. So if I were to use AG, I would tell it to ignore, like... Actually, I don't have to actually ignore my git ignore when I started using FZF I had to manually tell it hey g ignore my git ignore

so I actually thought that I would have to always tell it to ignore my git ignore but actually not so I actually knew something wrong I just realized okay I wasn't trying to call you out I'm actually trying to learn because i because i i tend to use grep just because it's familiar to me now i also use act but i usually only use act inside of like

the vim search tools i feel like at a certain point with act i used to have to tell it what kind of a file i was looking for like act dash dash pearl for instance or dash js if i just wanted to search javascript files Whereas grep will by default search every file in the directory. But I'm just going from memory there. I was just curious if ag had specific places where it'd fall down. But maybe we should just all be using ag

all the time. I guess so. I didn't know that. Well, there's one common thread that binds all these tools together. We've talked about the Unix philosophy. We've talked about small tools, you know, loosely coupled. And the idea of, you know, sending your input and your output between these tools by piping.

And really what's at the core of that is this concept of everything is a file. And really the idea of plain text or just passing text around. And the beauty of that, you have another post called In Praise of Plain Text, which hilariously starts off how graphical interfaces are bloatware. So we've sensed a theme here with you, Lucas.

But go ahead and just riff on that, the concept of plain text, why it's so powerful and why it's so useful in this context. So I think that just having this interface readily available for you to integrate and combine programs makes it so easy for you to achieve tests. And also I think it kind of encourages good design

because when you're writing a program that needs to work by itself, that cannot communicate or that it's hard to communicate with other programs, like when you're using a program that needs to work by itself, that cannot communicate, or that it's hard to communicate with other programs, like when you're using a GUI, it's often hard to pass data from that GUI into other programs, whilst when you're using text interfaces, it gets quite easy to do that. So since you don't have to worry about putting all those features into a graphical interface,

that's a very important thing in Unix philosophy, just doing one thing and doing it well. So I think programs get a lot smaller. And when you have less software, you have less things to worry about. You have less things to maintain, less things to update. There's less places where bugs can hide. So I think it not only makes it easier for you to accomplish tasks, but also encourages good design in general.

And I also think that another thing that's important here is that when you're using GraphQL interfaces, often the creators of GraphQL interfaces have to be thinking about, hey, what are our users going to do? What should we provide them with?

While if you're writing a CLI tool, you should just be concerned about what I want this specific tool to do. What's the smallest thing? What's the real purpose of this tool? Because whatever else they want to do with the output of that or whatever they want to provide as input is none of their concern. So I think that's really useful when developing an application

is both from the point of view of the creators, because for them it's a lot easier, because they have to assimilize things. And from the point of view of the user, where it becomes a lot easier to use them in whatever way they think it's more suitable so they can accomplish a wider range of tasks, I guess. I like the way you end that post. Text is timeless, precise, and elegant. We should use it more. Yeah, I think that when you're communicating to a machine, you know, it's kind of like when you

know like the language of mathematics, you know, it's just a lot more precise. Yeah, I think it's just so simple. So I quite like the idea of not having visual abstractions or all these visual concepts or things that you have to have seen before to understand what they do. When you see a symbol, that's a common idea between us humans. There's a common agreement between us that this symbol does this thing. So if you're not, if you don't know what a certain symbol does

or if it looks confusing in a certain way, it's just subjective while text is just precise. just precise you know you tell the computer precisely what you wanted to do and there's no subjective in that you know there's no searching around for buttons or you know there's no looking for an icon or not understanding you know like not finding something you know it's just it's always there it's just exact and precise and you know as i said it's timeless well you aren't going to get any disagreements from me on that one. Huge fan of plain text.

Huge fan of Markdown, which has similar precepts and really allows you to write prose, not engineering necessarily, unless you're doing documentation, but just the idea of writing prose to be read in a plain text format, at least a format that is readable and legible and enjoyable in plain text, but then can be converted into HTML or any other format for other needs, I think is the simplicity is probably one of the reasons why Markdown took off

and became kind of a de facto language for technical writing. Are there any resources you can share that's something you track pretty often? Maybe a text mode only newsletter or something like that? Yeah, so I tend to go to a lot of conferences. So I talk a lot to people about what are they using, and especially since whenever I'm doing live coding or whenever I'm using my Mac I'm in my terminal like I'm quite

approachable for people that also you know use CLI tools quite a lot so I think interacting with people is like a very valuable way of learning these things you know sometimes you you know I think as I've said one of

the one of the motors for one of the main motivations for Because, you know, sometimes you, you know, I think, as I said, one of the, one of the motors for, one of the main motivations for wanting to, you know, use the terminal more is to get

more efficient what you're doing. You know, when you get annoyed, you go there and you fix, and you try to find more efficient

ways of doing things. But sometimes you don't realize that you're missing a more efficient way of doing things because

you think that what you're doing is already efficient enough, right? So I think that's when talking to people comes and makes it easier for you to realize what are the things that you could be improving, but you aren't because you think they're already good enough. So you're missing treatments on both points. I also, on GitHub, I'm always looking for people's.files to see what they're using. I think that's quite useful. I think I learned a lot by reading other people's.files. So yeah, just seeing what's in there, you know, like how they use things, how they use tools, you know. Asking myself why a certain piece of configuration is there. I think that's also very useful.

And also, I find quite a lot of useful stuff on Hockey News, on Twitter. So I guess those are the ways I keep myself updated when it comes to that. I can say that I've learned a thing or two reading your.files, Jared. Really? Yeah, because you do some interesting things with bash history or just your RC file,

just different things that have been in your settings I've learned. Even though I don't use bash all the time, this is back when I did. I always appreciate looking at somebody else's.files. And just because you'd mentioned that, Lucas, I was like, you know what? I wonder, since we're such an awesome repo kind of fan place, Jerry, where we're pretty much anything that's awesome, awesome.files, awesome Vim, awesome whatever, we're going to try and log it.

I found awesome.files. I was going to say, I guarantee there's an awesome.files out there. Yeah, it's a curated list of.file resources, so you can jump into a lot of different stuff. I think that's a great point, Lucas, to find learning, which is what I was trying to get at was like, you know, for those listening, where can they find some good resources to just learn themselves?

You know, a lot of it is paying it forward by writing a blog post about where you've been, like you have, and both of these scenarios to sort of give representation and give a path forward for, you know, somebody coming behind you. And I think the, you know, reading somebody's dot files is quite enlightening sometimes. It's like, wow, I didn't even imagine doing that. Or that's really interesting. Like, I think you were doing something in particular with history,ared i can't recall what but that's the one thing that sticks out to me about your dot files i was really i think you had your history like an extreme amount or something like that like 30 000 or something as big as it would possibly go yeah because why

wouldn't i want to have all that of course that's my my same idea but i was like i didn't know i was able to yeah alternative to that is have no history. That way no one can track your moves. That's right. That's the ninja move. It erases their history as they go. Yes. But I'm the hoarder.

I'm just like, well, I'm going to keep as many lines as I think it's just set to the max available. Because we have the resources now. I think the history command was probably written back in the day when people were dealing with size constraints on their disk, but no such problems. Well, it makes me wonder if, so I agree with.files in terms of a way of learning tips and tricks from other people, but it's so much more useful if somebody actually just walked you through their.files or explains why they do what they do versus just trying to conjure their intent or hopefully have comments on what they're doing. So I'd be curious if you guys, you too, but also the listeners, if you'd like to tweet at us or something or comment on this episode on change.com, if you'd be interested in watching like kind of like a, maybe not a live stream, but a video where somebody would actually

walk you through their dot files or explain some of the more interesting tidbits in a, in a screencast or even just two people sitting there, one person asking questions, one person answering. Because it seems like that's a more digestible format for me versus I'm not just going to go troll through other people's.files anymore. Maybe back when I was in my early 20s, I would do that. But if somebody served it up to me,

like here's a person who I respect and here's why they're doing their.files the way they are I think that might be interesting. Is that interesting to either of you two? It's interesting to me. I think that's the better way probably to do it. A good first pass would be accessible.files. Second pass would be

explainer please. And I think also just like seeing things in action so that you can realize how that actually feeds into someone's workflow you know also just like seeing things in action so that you can realize how that actually feeds into someone's workflow not just like seeing a tool there and knowing what it does but not knowing how someone uses it

so I think that's quite a useful thing to know also too like what we did this isn't exactly a one to one but we've got Lucas questioning iTerm2 just by looking through his choices. A critical eye. Yeah.

Maybe Terminal actually is probably just fine. It's kind of like code review or working in a pair when you're all by yourself and you do things. You just do certain things, and then when you're with somebody and you have to explain, teaching does this to you as well. And someone's like, why do you do it that way? And you're like,

why do I do it that way? Why am're like, why do I do it that way? Hmm. You know, why am I using I term too? I'm not sure it made sense at the time. Maybe I don't need it anymore. So yeah, that's, that's always an enlightening experience for everybody. Well, it's been a fun conversation, Lucas. Thank you so much for, you know, sharing your thoughts in these two blog posts. I know that you gave a talk at NebraskaJS,

which, Jared, that's where you learned about Lucas from before. That's right. And then this awesome blog post, How I'm Still Not Using GUIs in 2019, which is a guide to using Terminal. So for those listening out there, if you haven't read this, we'll link it up in the show notes. Do a deep read into this.

Shares his.files, a lot of the stuff we talked through, obviously. All the links will be in the show notes. But, Lucas, into this. Shares is not files. A lot of the stuff we talked through, obviously, all the links will be in the show notes. But Lucas, thank you so much for your time, man. I appreciate it. Thank you very much. I love the show. I'm really happy to be here. And it was like a really nice talk to you guys.

Thank you. All right. Thank you for tuning into this episode of The Change Log. Hey, guess what? We have discussions on every single episode now. So head to changelog.com and discuss this episode. And if you want to help us grow this show, reach more listeners and influence more developers, do us a favor and give us a rating or review in iTunes or Apple podcasts.

If you use Overcast, give us a star. If you tweet, tweet a link. If you make lists of your favorite podcasts, include us in it. And of course, thank you to our sponsors, Linode, Clubhouse, and Rollbar. Also, thanks to Fastly, our bandwidth partner, Rollbar, our monitoring service, and Linode, our cloud server of choice. This episode is hosted by myself, Adam Stachowiak, and Jared Santo. And our music is done by Breakmaster Cylinder.

If you want to hear more episodes like this, subscribe to our master feed at changelog.com slash master, or go into your podcast app and search for Changelog Master. You'll find it. Thank you for tuning in this week. We'll see you again soon. All right, because you've stuck in here to the end of the show, got a surprise for you. Here's another preview of our upcoming show called Brain Science. This podcast is for the curious. We explore the inner workings of the human brain to understand behavior change, habit formation, mental health, and the complexities of the human

condition. It's hosted by myself, Adam Stachowiak, and my good friend, Muriel Reese, a doctor in clinical psychology. It's about brain science applied, not just how the brain works, but how we apply what we know about the brain to better our lives. There you go. That applied brain science really stood out to me because I want, I don't want it to just be data. I want you to go, how can this fit? What can I take away now? How am I going to change?

And that that sort of is where you come in more. And even some of the questions like, so like, I want to ask you, what are some of the most challenging things working in the tech world when it comes to relationships? Probably the most important one is isolation. More and more of the world and companies are being, for good reasons, they're being okay with what they call distributed teams. Yeah. And that means that you and I, we work for the same company, but you work from your home office. I work from my home office. I might go into the office a couple times a week if I live local, but even if I live in San Francisco, I'm still probably a remote worker,

even though I can hop in an Uber or hop on, you know, the train or whatever and go into the office and be there in a half hour. But why waste the time? You know, and this is where I would revisit what I want to talk about with resonance and that whenever we're learning, no matter what thing, it's really helpful when we get feedback that's both immediate and specific. And so when you're by yourself, and you don't have any interaction with other people, how can you get any feedback? I mean, you're losing most of the nonverbal communication. And you also don't have all of the voice inflections or facial expression. Have you ever tried to be sad, feel sad and smile at the same time?

Try it. It's pretty hard. Right. Because facial expression is exactly what's involved when it comes to empathy, which is relationships. I was reading a research article recently and it talked about, you know, how couples who are together a really long time end up sort of looking like each other. Yeah. And so what they've looked at is when we actually empathize with other people, facial expression is really key within that. And so when you empathize with the partner you're with over and over and over again, your face begins to make the same creases and facial expression as it relates to where somebody else is emotionally. Wow. Right?

Say it is. So that's creepy. Well, again, this is sort of the hotbed when it comes to neuroscience these days is mirror neurons. And these mirror neurons are what are involved with empathy. And so mirroring, meaning I get another person's emotional world. And so one of the research studies looked at Botox. And what they found is that Botox, because it actually assists in paralyzing facial muscles, then you can't contort your face, so you don't get wrinkles. But actually, levels of empathy go down. Right.

Because your physical appearance can't reflect your inner appearance. Yeah, you got it. And so when you're working in these remote locations, it might facilitate better work or more focus. And it allows people to be distributed and to capitalize on the talents across the country, right? Yeah. So that's like a treasure trove, in my opinion.

Talking about in a scientific way, you know, not just like, hey, this is my opinion. Yeah. About all the cons of that. Because I think what we can do is still have remote work, but do it in more healthy ways. Because I'm fully, I mean, I've been self-employed remote worker since 2006. Now I'm a unique animal. I know that. My wife knows that.

Right. I'm fine with it. I'm a good human being, but I've got some flaws and I'm willing to accept and share those to some degree. And I think the problem is we just lack maybe a more purposeful or intentional feedback loop. Yeah. more maybe a more purposeful or intentional feedback loop yeah which i think is super important to being able to operate in this world in just good ways i don't know healthy ways it's probably the best way to use in this show context is healthy ways that's a preview of brain science

if you love where we're going with this send us an email to get on the list to be notified the very moment this show gets released. Email us at editors at changelog.com. In the subject line, put in all caps, brain science with a couple bangs if you're really excited. You can also subscribe to our master feed to get all of our shows in one single feed. Head to changelog.com slash master or search in your podcast app for ChangeLog Master. You'll find it. Subscribe, get all of our shows and even those that only hit the master feed. Again, changelog.com slash master. Thank you.