NOEL: Hello and welcome to Episode 52 of the Tech Done Right Podcast, Table XI's podcast about building better software, careers, companies, and communities. I'm Noel Rappin. 

On this episode, we're talking about developer tools. Developers use a variety of tools other than their programming language to get their jobs done. Our guest this week is Brian Hogan, a Technical Editor for Digital Ocean. Brian's a prolific technical educator, writer, and editor and he's currently the author of the book Small, Sharp, Software Tools from the Pragmatic Press. We talk about why command line tools in particular are important, what command line tools do well, and why some people including myself often find them opaque and confusing. We talk about our favorite tools and about customizing your workflow to fit your needs. What are your favorite developer tools? Which ones did you find hard to learn or do you consider particularly important? Let us know at http://TechDoneRight.io/52 or on Twitter @Tech_Done_Right.

Before we start the show, I have one quick message. Table XI offers training for developer and product teams. If you want me to come to your place of business and run a workshop on testing or Rails and JavaScript or Legacy Code or estimation, I would very much like to do that. Also, if you are in the Chicago area, be on the lookout for monthly public workshops starting in early 2019. For more information, email us at workshops@tablexi.com or hit us on the web at http://TableXI.com/workshops. And now, here is my conversation with Brian.

Brian, would you like to tell everybody who you are and what you've been doing?

BRIAN: Sure. I'm Brian Hogan. I'm a web developer, educator, lifelong learner, and I currently work at Digital Ocean as the Editorial Manager for our Write for Donations Program. I'm the author of a book called Small, Sharp, Software Tools. It's a book on learning how to use the command line. It starts out very gentle, very basic for beginners and then kind of ramps up through the rest of the book. So, I'm hoping that there's enough in there to get people who are new to the CLI excited and something in there that delights people who already feel they're very confident around the CLI. So, I'm really proud of that. And that ends up being the 10th book for PragProg that I've done. 

NOEL: Ten is a lot. That's a lot, and that's coming from somebody who also has more than one which is a little unusual. So, let's talk about command line things. We're recording this a couple days before Thanksgiving. I just got back from RubyConf where I was part of basically two back-to-back talks. One of which was about, not mine, was about using the command line and about dot files and things like that. And mine was a little bit about command line, but more about thinking carefully about the tools that you use whether they're command line tools or whether they are not command line tools. What's the biggest benefit do you see for developers, especially novice developers, becoming really comfortable on the command line?

BRIAN: I think there's a couple of things. One of the things that I believe strongly in is that that's where the real levers and power is to your operating system. And we kind of have this, the GUI is there for people who are the average users but I don't think that software developers we fall into that category of the average user. And so when I look at the CLI, I look at it as a bunch of small little pieces that you can then put together to create more complex workflows that you can get stuff done with. And I think that appeals to people who are novice programmers because it's the sort of the first step to understanding automation. The idea that you can take a handful of tools, chain them together and create a pipeline that processes some data that's sort of what you learn about when you're new to programming. You have some inputs and you process it and you produce some kind of an output. And so that model kind of falls squarely there on the CLI.

The other reason is that the frontend world especially has really embraced CLI tools, things like Create React App and things like that. And so you're asking these new jobs with developers, "Hey, we're going to throw you in a command line interface in order to run this Create React App." And so I think that's important that people who are thrown into that kind of environment should feel comfortable and confident that they can do more than just that.

NOEL: I have complicated feelings about this. This is actually the background story that I didn't tell, I forgot to tell it in my Ruby Conf talk. Which is that when I was a college Computer Science undergrad, our first class, we used C as programming language. This is in the early 1990's. It was not my first class but it was a very early class in the sequence. And we were all supposed to be in a lab with dumb terminals that all were off a central server because that was what you had in computer labs in 1990. And we were supposed to turn in programs using this, but they never taught us how to use the command line. They never taught us how to use the UNIX system at all. They were teaching us C, so they weren't teaching us the command line. Some people knew it and I was not one of them. And I just got super frustrated and wound up going back to my dorm which was much better lit and had better snacks and used like Borland Turbo C and turned everything in with that. Ever since then, I've had this relationship with command line tools where I've gotten better at using them but I also find that their sort of general opacity and lack of user experience in their design to be kind of frustrating and yet acknowledge that they're tremendously important for developers to be able to work their way around. As you say, like there's a ton of developer tools that are only accessible or best accessible through command lines. I'm wondering how you think about the developer experience or whether you see that complexity as being a barrier to developers as they start.

BRIAN: I've always thought it was a bit of a barrier entry and that's why I actually started including them in the courses that I taught. In 2012 to 2016, I taught a first semester course for software developers and most of the course was using the command line because I knew that they were going to encounter it in the rest of their coursework. And I found through doing that, because when you do something like that and then you iterate on it, you figure out what worked, what didn't work. You test all your assumptions, you get feedback from people who are learning, you see where are the holes, where are the things that don't make sense. But it turned out that it was a great gentle way to introduce students to the concept of automation and problem solving. At least you could say, "Well, I need to create a file with this many lines. Here are the tools that you have in order to do that. How do we do that?" And so, from learning the concept of computers if you've never written a line of code before, they're an interesting way of doing it because you see a lot of what happens when you click a button in a GUI. These are the things that kind of have to happen. It removes some of the abstraction away when someone's looking at learning to program for the first time.

I think the other issue, and this is what you're hitting on in your thoughts, is why I sat down to write this book, because I do think that a lot of the problems that people encounter with the CLI is that it's not very friendly. I don't have control over the tools to make them friendly but I do have control over how to present them in a way that makes sense and is welcoming and empowering for people who are new. And so, that's what I'm trying to do with this book is I'm trying to say I'm not going to cover every single possible option but I am going to say, "Let's look at this from, here are some problems we need to solve and then here's how you can use these tools to solve these specific problems," because I think that sort of takes away, because if you look at the man page for something, it's like, "Wow! That's a lot of options there." But really, when you start thinking about like if you're a software developer, an experienced software developer who has used the command line, you're probably very capable of creating a very quick command to look at your command history and see what the most used commands are, which is kind of what I did. And that's what helps you figure, "Okay, what do people really need to know?" They don't need to know everything but they need a good starting point. And I think that's the trick with the CLI is ease people in, get them confident feeling what they need to know. And then just like programming, you solve a few problems. Now you need to solve a little bit bigger problems, so you expand your knowledge and you go out with that. And I see a lot of the resources that I've come across in the past, they just throw a huge mass of web pages out and just say, "Here, just go. Type these commands, do these things." And I don't think that's helping anybody.

NOEL: Yeah I definitely think it's true that historically this has not been a topic that gets explicitly taught from first principles. It's sort of assumed that you sort of know it or it is taught kind of along the way, like a lot of programming books or resources will say, "Go to the command line and type this to get started," but they won't say like, "Here's what you're actually doing on the command line. You are interacting with a special kind of program called a shell," and they talk about it at first principles. What do you see as the concepts that people struggle with or never really quite internalize when they're dealing with Unix command line tools?   

BRIAN: I think it's more that they cargo cult things,

NOEL: God, yes.

BRIAN: Like they'll get an answer from Stack Overflow and that's the command that they will use. They will just use that command over and over again. How do you get a directory listing? Well, you just type `ls -lf`. Do you always need the L? Do you always need the F? Why are you doing those kinds of things? How do you look up the processes on your machine? Which command is it? It seems you kind of learn from memory because you picked it up. You don't really necessarily understand what you're doing or why it works. You just do it and it becomes this rote thing that you do. Similar to like if you use Rails - `rails new`. That's the command. `rake db:migrate`, that's the command I use. It takes someone for example who's been doing Rails for 10 years, convince them that they should use `rails db:migrate` instead of `rake db:migrate`. It becomes like muscle memory thing that you just do. And I think that's kind of the thing is it's the lack of understanding because as soon as I started to figure out how I can actually use things like awk and sed in my daily work, the light bulb came on for me. It's like, "Oh! I don't have to open a text editor for this kind of stuff." Or, "Oh jeez, I don't even need to write a CSV parser for this very trivial thing I'm working with. I can do that relatively quickly here."

NOEL: Sure. And we should probably quickly say what awk and sed are.

BRIAN: Awk is a programming language in your shell. It's a very interesting text processing language. People see a command and the most common uses for it are like pluck out pieces of text in some output somewhere. You might take a directory listing and you'll send it to the awk program and then you'll print out one of the columns or something like that. But it's actually a very much more complicated programming language that you have access to, to do text processing. Sed is short for stream editor and you can use it to transform text as it comes through, find and replace stuff and you can even use it to prepend the line to a text file, append the line to text file, even insert text from another file into an existing file. So, you build a whole templating language out of those two tools if you're so inclined.  But I think that's kind of the powers that you have all this stuff at your disposal and it's there on so many machines. Microsoft has really been putting a lot of focus and effort into bringing the Linux, the Bash shell, a proper Bash shell to Windows now. And if you're in Windows 10, you can take advantage of that which means you have these tools where 10 years ago, people used to be like, "I'll just go install Python or Ruby or something on this machine because I need these kinds of tools and this OS doesn't have what I'm looking for." And so now by learning a handful of these really interesting tools, you don't have to do that so much. It might be easier sometimes to use your favorite programming language of choice but it's nicer to know that you don't have to and you can cobble together some pretty great workflows to get some stuff done by just learning some of these tools.

NOEL: There was about a six-month period where I felt like I actually understood sed and awk enough to use them, and then I didn't need them for a while and it's now gone away.

BRIAN: Yeah.

NOEL: But yeah, there's this whole concept of kind of the Unix command line flow of you have a number of small tools that do one thing and transform a piece of text, that whole sort of text processing chain of `grep` for doing regular expression searches and `sed` and `awk` and a couple of other stuff, `cat` and a couple of other things that I'm probably forgetting. I guess you're talking about it as being like a stepping stone to full programming which I guess is it's certainly not how it was developed but is kind of what it looks like now.

BRIAN: Functional languages are becoming this huge deal now. More and more programmers everyday are taking a look at things like Elixir and F# and the various kinds of things. A lot of them just have this thing in common where they encourage you to create data pipelines. They encourage you to take the result of one function. They actually have operators, these pipe operators that will do that. And you're learning the concept on the command line of 'use this tool to solve this problem then use this tool to solve this problem and then pass it to this tool to solve this problem'. And that's a really good sustainable way to think about software development too. Use this function to solve this problem then use this function to solve this problem and then use this function to solve this problem. We've all seen what happens when you have one function that does way too many things. And I think that when you're thinking about it from the very beginners' standpoint, it really is kind of refreshing to start thinking, "No, I don't really need this tool to do all of this work for me. I can use this tool to do this piece and then I can kick it over to this other tool to do this part of it." 

NOEL: There's a real power there and it's a real power that you sort of deny yourself if you commit yourself to cargo culting. And the, I want to say, ethos of cargo culting is just up and down the way that the developer communities interact with the command lines. It's the 'I have this `.vimrc` file that I got from somebody else who got it from somebody else who got from somebody else' and nobody knows what all of it does. The joke about there only being one person who understands Emacs configuration files has been around like since I was a college student, at least. And what I would advocate I think is sort of being thoughtful about understanding the tools that you learn and trying not to be dependent on stuff that you don't understand. I don't know. But on the other hand, I use a bunch of Z Shell aliases that I don't completely understand. I mean, I kind of know where they came from, but I do have a couple of things that I depend on that I don't know very, very well.

BRIAN: I think for me, it's been mostly some kind of text transformation, some kind of automation, things like that. Those kinds of things come up a lot, whether I'm giving a conference talk or whatever, or just doing something as part of my daily routine. One of the things that I wanted to do recently was I gave a talk and I knew that the slide deck was going to be online. I've had some situations in the past. I've spoken on two separate occasions where the lights have gone out and the projector system has gone out. I always have a backup plan. I have the full slide deck available online where people can grab it on their phones so we can kind of follow along similarly like a 1980's style film strip where we just go to the next slide, go to the next slide which is interesting. Since that happened, I always have two versions of my slide deck. I always have like one where my typical style is to introduce something and then just kind of live code and discuss and talk through something. But when the lights go out and the projector system goes out, you can't live code. So my backup plan is to always have that stuff in the slides. And that helps then when I want to share the slides online because then I don't just have a few slides and then a thing that's just demo and then you can't follow along. I have the whole slides in there.

I started doing my slides in Markdown. And so then what I ended up doing was putting some comment strings in the Markdown document. And then with a really quick makefile, I can produce the long version of the slides and then create small versions of the slides by using sed to find and replace and inject comments to comment out the slides where the place holders are. And just the idea that I don't need a separate programming language do that, it really is a single `sed` command that replaces a string with some comments and a makefile which I just have. I just happen to have make there on the system that I'm using. I didn't need to write a program to do this or anything. I'm just leveraging the tools and then using a command line tool to generate my slide decks.

NOEL: Make being the tool that is a longstanding Unix tool that is used to describe generating files from other files.

BRIAN: Yeah. I mean, you can use it as a task or use it as a task language if you're familiar with all the other ones like `rake` and there are so many. Everybody's reinvented `make`.

NOEL: I tend to reach for rake in those situations because I understand it and because makefiles are like legitimately confusing. I think it's funny that...so, I also write presentations in Markdown using a Mac app called Deckset to render them.

BRIAN: Yeah, that's what I use.

NOEL: Right. I get very frustrated when I'm editing a Markdown Deckset file when I want to move slides. So the way that this works is there's Markdown and there's like a delimiter between the slides. And I always forget like when I'm cutting and pasting whether I've pasted the delimiter or not. And I always want to just drag a slide. I just want to drag things around. And you can't really do that in the text file. So what I did was I built an Electron app using Elm that parses the file and gives me a GUI for Deckset and then saves the file back out and it does a couple of other cool things that are a little tricky to do directly in the editor. So I think that's really funny that your instinct is to reach for command line text processing. And my instinct, admittedly I also wanted to just play with Elm.

BRIAN: Oh, yeah. Who doesn't? It's great.

NOEL: Yeah. And just like, "Can you build an Electron app with Elm?" And the answer is, "Yes, you can." And it's actually pretty cool. But I think that that's really funny that your instinct is to reach for very powerful text processing command lines, and mine is to reach for writing my own GUI.

BRIAN: That's the thing. It's funny because I could see myself doing that. I could see myself sitting on and I'm trying to prepare a conference talk so I'll bikeshed and yak shave by building a GUI app. I could see myself doing that exact same thing. But it was just like, "Hey, I just wrote this chapter on `sed` and `awk` and things like that for this book. I probably should put it to some use here in various different ways myself too." When you know how to use these things, these opportunities just start showing up. It's the weirdest thing. "Oh, I can solve that problem relatively quickly. That's neat."

NOEL: It's definitely true that as you start learning these things, you definitely have the 'oh, I have a new hammer, everything looks like a new nail'. If you learn `grep`, you suddenly see uses for `grep` everywhere. And conversely I have found that keeping these tools top of mind in my day-to-day environment becomes a problem.

BRIAN: Yeah.

NOEL: How do you deal with that? Is there something you do to remind yourself of cool shortcuts you could be using or tools that might improve what you're doing?

BRIAN: Well, it's a little different for me because I found myself in this strange world where I'm writing code, I'm creating tutorials, and my day is spent on the command line. Part of the work that I do for my day job is testing out a tutorial that somebody sends in, which means I'm on a server somewhere, typing out commands and being able to do that quickly. I got to get the testing done quickly to verify that things work so we can move the thing towards publication. So being efficient at that becomes a very important thing. So, what ways can I be efficient at that? Well, one way I can be efficient to that is take a Markdown document and very quickly write something quickly to extract all the commands from the document so I can just see a list of all the commands that need to be executed on the servers. So, I have that, the different things that you start seeing. For me, to keep it top of mind, I'm using them every day. It's very much like how do you get really good at using a programming language? One way to get really good at it is to use it all the time. If you write a thing with Elm and you go, "That was awesome!" And then you have to go back to writing in Python for your job all day long, you look at your Elm app three months from now, you'll probably not going to remember how any of it works, right? And I think it's the same thing with command line tools. It's like everything else, every other thing that you want to learn and commit to memory, making an active effort to practice those kinds of things and gain those skills if it's important to you, if it's valuable to you. And I'm not saying that it has to be valuable to everybody. But I am saying that if it is something that you do feel motivated to learn, chances are you'll probably spend a lot of time doing it. The `ls` command is a great example of that. It's something that doesn't make sense when you first run it but it's one of those things you just use so much that you don't even think about doing it anymore. You just start using it over and over again.

NOEL: Yeah, that one I remember.

BRIAN: Yeah.

NOEL: At the same time, I have somewhere on my command line, a shortcut to it. It's like a better humanized version of the listing which I genuinely think is better when I remember to use it which is about never.

BRIAN: Well, it's really funny because you start noticing when you start doing things like testing a command line book on various operating systems to make sure you've covered all the bases, for example, you start noticing how many operating systems ship with an aliased version of the `ls` command. And you don't really realize that but I think Ubuntu's desktop version aliases the `ls` command by default so it shows colored output.

NOEL: Yes.

BRIAN: You don't really realize that they've done that. You just go, "Oh! Hey, that's handy and confusing." 

NOEL: That's handy. That was the alternate title of the book: That's Handy and Confusing.

BRIAN: Yes.

NOEL: Yeah, I do that. I actually recently tried to figure... because I have built up. Like I think many longtime developers, I have a command line practice that involves a couple of things that I know pretty well and a couple of things that I use intermittently and I'm not sure where they come from. I'm very dependent on the particular keyboard shortcuts I use for searching command history and had sort of forgotten where they came from. They actually come from the Z shell, Oh My Z shell plug-in for command history. I actually really went back in and audited, all the stuff that I use regularly and tried to remember where it came from and tried to figure out if there was a better thing than what I had gotten used to doing, which was actually a very valuable thing to do was to look at the things. Even if you're not a novice, if you've been doing this for a while, to look at the commands you use all the time or the aliases you use all the time and just like where are they defined? Do they still make sense? Is there a better thing to do this?

BRIAN: That's so very true. For me, I've had this desire. It goes back to even when I was using TextMate, before I was using Vim. I've been on Vim for over 10 years now. But before that, it was TextMate. What I learned from using TextMate was that because everything I used before then, I was sort of at the vendor's mercy. I started out my career using Visual Basic and those IDEs. When I was programming just as a kid, I was using whatever tools I was given, whatever IDE was for the tool. And when I got TextMate, I realized I could make my own keyboard shortcuts for things and I could make my own text expansions for things and I could really write my own plugins for it. And the same thing kind of carried over to Vim, I sort of got really excited about the prospect that I, as a software developer, can actually take these things and apply them to my programming environment. And once the terminal, once the CLI, became my programming environment. It became even more exciting. Once I understood how to use all these little tools, I can now make a customized prompt that shows me the information that I need or I can create my own key bindings in the shell that work on any program that uses `readline`. Whether I'm in a Python interpreter or the Ruby interpreter, I can create text expansions and keyboard shortcuts, ones that I have because I always forget. There's so many programs that take command line input but you have to put double quotes on them, otherwise you'll run into some kind of weird shell escaping thing. Occasionally, I need an exclamation point in a Git commit message or something like that. And sometimes, I always forget to type the quotes out, and use a couple of keyboard shortcuts that jump to the beginning of a line then jump to the next word and then enter the quote then jump to the end of the line and ends with a closing quote. And I was like, "I could just make a keyboard shortcut to do this because I'm forgetting this so often. Let me just make that." And I think that's the thing that really appealed to me and is something that I discovered many years ago that I can really make this my own. I'm not at the mercy of someone else, just like if you're using a text editor where you can create your own highlighter if you need to. If you're working on a cutting edge programming language and the editor that you're using doesn't support it, if the editor offers the ability for you to create a tokenizer for that language, you can start doing it now. You can create that now. You're not on some vendor's mercy. That always appealed to me. And so the same thing holds true with being able to create any kind of shortcuts or build systems that I need to be able to create. And eventually, somebody else will make a better one and I can not use what I'm using anymore they'll do something better. But at least I'm not held up and I can still be productive and I can own that productivity.

NOEL: Yeah, I think that it's definitely true. I had kind of a similar relationship with TextMate and actually the thing that I'd used right before it but where I got very excited in being able to customize it and create snippets and things like that, and that carries on. I don't use Vim but I do use environments that are highly customizable and do tend to customize them because...

BRIAN: That's where you spend all your time, right? It should be comfortable.

NOEL: Right, yes. This is your tool box, right? You should understand your tools. I also think that you were talking about bash prompts, the prompt, and I think it's my kind of experience that that is a very frequently cargo-culted piece of kit, the prompt. And one of the great things about setting up your prompt right is that if you do it, you will get continual benefits from it without any effort furthermore because it will just show the useful information. I love tools like that where I can set it up where I can do a little bit of customization and now I get a benefit with no cost. I can always tell whether my Git repo is dirty now just because that's on my prompt. And it costs me no ongoing effort. My question, I guess, is are there any other tools that you feel like have that kind of very, very high benefit to setup/cost ratio?

BRIAN: I think the prompt is a big one there. But I also think using aliases and functions in your shell to supply those default arguments to things. The idea of an `ls` command that the OS has overridden to include colors, I mean, that to me is smart. If you just find yourself typing the same command line options over and over again for something, creating an alias for that to save yourself some time, that's incredibly beneficial because it has these compounding benefits over and over again.

NOEL: One thing I recommend for aliases is to optimize them for ease of memorization and not golfing the lowest amount of keystrokes.

BRIAN: Right.

NOEL: So, like `ls_`, I don't know, `ls_nice` or something like that rather than something cryptic. I find I have a limited memory space for cryptic three and four letter acronyms.

BRIAN: Yeah.

NOEL: But I can remember things that are short words.

BRIAN: I think that's a really important one. But I'll tell you the one that saves me time. I made a function. It's called called `mcd`. I'm not the only one who's thought of this. Looking on GitHub, I see like 40 different repos that people have done this. But it's an a command called `mcd`, it's a bash function and all it does is create the directory and then switches to it. It's stupid but it's like how many times have you created a directory and then had the cd to that directory? Well, just make a command that does that for you, and that's kind of the thing that I really like about using the command line interface. That's a small example of something that you can find a way to shorten that. I only type one command instead of two. 

NOEL: By the way, one thing for Ruby developers is there's actually a command line program which I think is called `rb`. I'll put it in the show notes. It might not actually be called that, which lets you like create...it's a very, very small little utility that is essentially a wrapper around evaling Ruby that makes it work with Unix pipes in and out. And I use that to do a couple of things that you might otherwise reach for `sed` and `awk` for, but already know how to use Ruby. So you just pipe like three or four short one line Ruby commands next to each other and do the same kind of text transform.

BRIAN: And one of the things that we really haven't talked about which I think is kind of interesting and surprising is that one of the issues that can make learning the command line very difficult is that you have the GNU tools, the GNU Linux tools on things like Ubuntu and then you have the BSD versions of some of those onto your Mac. And so, you might look at something online and go, "Oh, that's how you use it." And then you try it and it doesn't work because there's just differences in some of those tools and sed is one of those. The sed that ships on the Mac is different in how it behaves than the one on Ubuntu machines, for example. And with things like Homebrew, you can certainly install the other version of sed but it is one of those things that it creates a bit of dissonance for people who are trying to follow along on tutorials online. Those tutorials aren't really explicit that there might be differences in the versions that you're using or the tools that you're using. That creates difficulty. It's created difficulty for me when teaching it to an audience that I don't control, like I don't know what OS they have and it creates trouble for people when they're trying to do their own independent learning.

NOEL: I noticed that you spend a lot of time in the book being very aware of that issue and especially at the beginning having people set up and having multiple versions of commands depending on what operating system. But I think eventually you ask people to set up an Ubuntu virtual box and go from there.

BRIAN: Yeah. Because I want them to focus on learning the thing. You don't have to do that but I do make it clear that I'm going to use the Linux versions of everything throughout the book and that's for two reasons. One, it's not that I don't use a Mac. I love the Mac. I have a Mac. That's my primary computer. But Microsoft has kind of gone all-in on their bash for Windows that defaults to Ubuntu, so you're going to use apps to install stuff on there. You're going to use the GNU tools for all that stuff. And so, the Mac is the one that's the oddball. So, I went with that because I want people to focus on learning the commands not fighting their operating system. I learned that the hard way teaching these things to actual live humans in an environment where you can get continuous feedback and see where these things break down. And so, that's where a lot of stuff from the book comes from. It's my experience in classrooms and workshops, kind of knowing where people are going to run into trouble and knowing that, "Okay, this is a point where there was a lot of contention. This is going to need further explanation.".

NOEL: What's a tool we haven't talked about that people should know better than they do? 

BRIAN: First of all, there's like built-in ones that you should know better than you do. Then there's additional ones that are indispensable parts of like my workflow. But I think that there's a lot of advantage learning how to use sed. I really do. I think that there's so many things that you can do very quickly with sed that I think might surprise you and delight you. There have been times when I want to generate a file and I want to put a date stamp at the bottom of it, and that's easy. But I want to put something at the top of the file. And I don't have to open up an editor or do any weird command line tricks to pull it off. I can use sed to do that and it's incredibly trivial to do with sed. You just insert something at the top of a file. I think that those are the kinds of things. If you spend a lot of time doing text processing, that's a really misunderstood command. It seems very scary when you're first looking at it.

NOEL: Arcane was the word I was reaching for.

BRIAN: Yeah, I'm going to be just more honest. It seems kind of scary especially when someone just gives you a sed command to run. But let's be fair. The reason it's scary is that it's using regular expressions. That's the reason why a lot of it looks scary. It's using a regex from something. And regexes are really hard to, first of all, to understand and I think one of the most difficult things to read. I like creating them but I hate coming back and reading them later on. So as a side note, whenever you create a regex, please save it to a properly named variable that explains what the regex is for.

NOEL: One thing that we've taken to doing in our code base is... Rubular is a website that lets you test regular expressions. And one thing that the Rubular website does is if you put in a sample regular expression and a sample text string that shows it working, it lets you create a permalink that recreates that regular expression and command line and we have taken to as a matter of course commenting regular expressions with links to a Rubular permalink that shows the regular expression in action.

BRIAN: Yeah. I've seen more and more people doing that. And I want to throw a plugin for something I have no affiliation with whatsoever, but it's a lifesaver for me and it's called Regex101. That website, you can paste or you can do the same thing with Rubular, you can paste in the regex and you can paste in a text block and you can also control which regex engine you're using. But it also breaks it down and tells you. It breaks apart the regex and tries to explain it to you and tells you, "This is what this is capturing. This is what this is applying." And it's very great for debugging somebody's broken regex, too. That's a life saver. When you inherit something that is not documented.

NOEL: Yeah. There's a plugin for Atom, the Atom Editor, which I've not seen replicated on other editors and it's called regex-railroad-diagram. And when you put your cursor over a regular expression, it puts a railroad diagram of that regular expression in the bottom of the window. 

BRIAN: Very nice.

NOEL: That you can actually see. It's really cool. I am not entirely sure why. It seems to have been abandoned and I'm not entirely sure why or why nobody's tried to do this for other tools. Anything that can help you visualize the complicated part is good.

BRIAN: We talked about like sed is a great example of a built-in tool that I think doesn't get enough love and it should. But I think there's another tool that I think a lot of people would find very interesting if they use it and it's called `entr`. You have to install it through your package manager. You can do it through Homebrew. You can do it through apt. Entr is a file watcher and a script runner. So, instead of installing something really weird and complicated to automatically run a test once the file changes or reload a browser when something changes, entr can just do that. It's small, it's incredibly fast, and it's an incredibly versatile tool.

NOEL: I don't think I'm familiar with that.

BRIAN: I think a lot of people aren't. But oh my goodness, it's great.

NOEL: We have just justified the last 35 minutes of your life, apparently. You're going to save all that time? This is the only episode of the podcast that has been time-ROI positive that we've we've ever done.

BRIAN: Okay.

NOEL: I'm very excited about that. Okay, we're kind of coming up on time. What else you want to talk about?

BRIAN: I'm fine continuing talk about things CLI-related. One of the things that is really important to me, we kind of touched on it briefly, one of the things that's really important to me is the idea of practice as part of continuous improvement. That's one of the reasons why I wrote the Exercises for Programmers book.

NOEL: Another great book. We'll put that in the show notes, too. 

BRIAN: On the surface, that book is like really trivial. The first exercise in the book is something I used to have my students do on the first day of class which is write a program that when you enter your name, it just prints back 'hi' comma and then the person's name and then an exclamation point. Simple string concatenation type of program. And so if you're doing it in Ruby, that's a one line. If you're doing it in Python, that's a two-line or one line depending on how you write it. It's not very complicated. Do it in Go, a little more complicated, involves a little bit more code, not too much. You're going to create a main function, you're going to have to import some stuff. Do it in Elixir, very, very small amount of code to pull it off. Do it in Elm, it's considerably more. It's considerably more code. And do it in iOS, and it's a whole different approach, a whole different ball game. And so, the purpose of the book originally was it was the exercises that I used daily in my introduction to programming class that I taught and to give students practice writing code before you assess them. I mean, I don't think it's fair. I never thought it was fair for people to just show you a bunch of stuff and then assess you on it and give you a grade on it. I think that the missing link to learning is practice and getting feedback on it before you actually attempt something.

And so, I had put those exercises together. And at the same time while I was teaching beginners JavaScript, I was learning Elixir. So I just like, "Well, I'm going to just write these things that I'm doing for my students. I'm to write them in Elixir." And holy cow, did it teach me Elixir. And I was able to dig in and learn those kinds of things. And now, I'm delighted when I see people share their solutions to problems in the book in various programming languages. And I'm delighted because it's showing me that they're practicing. They're putting in that little bit of additional time. If you're learning a musical instrument, you're going to practice. If you're learning a martial art, you're going to practice. If you're learning programming, you should probably practice that. And it's, a lot of times, pretty hard to get that practice because you've got some kind of a deadline coming up. So, I'm delighted that there are people who are able to find the time to read this book and I'm glad that this book gives them a learning pathway in order to pull that off.

NOEL: That seems like a good note to end on. If people want to talk to you more about your books or about command lines or learning development in general, where can they find you?

BRIAN: Twitter. Twitter is probably the best place: bphogan. 

NOEL: Okay, that's great. Brian, thank you very much for being on the show. I'm really happy to have finally gotten the chance to talk to you.

BRIAN: Oh, it's been great.

NOEL: Tech Done Right is a production of Table XI and is hosted by me, Noel Rappin. You can find Table XI on Twitter @tablexi and you can find me on Twitter @noelrap. The podcast is edited by Mandy Moore who you can find on Twitter @therubyrep. Tech Done Right can be found at TechDoneRight.io or downloaded wherever you get your podcasts. You can send us feedback or ideas on Twitter @Tech_Done_Right. And of course if you like the show, telling a friend, a colleague, your social media network, your boss, anybody else, they would all be very, very helpful. And a review on Apple podcasts helps people find the show.  

Table XI is a UX design and software development company in Chicago, with a 15-year history of building websites, mobile applications and custom digital experiences for everyone from startups to storied brands. Find us at TableXI.com where you can learn more about working with us or working for us. We'll be back in a couple of weeks with the next episode of Tech Done Right.