[00:00:01] Hi, this is Mark. And welcome to my podcast about code and bootstrapping. Today, I'm going to talk about automation, which is a topic near and dear to my heart, was actually one of the four themes of classic book by Brian Kernighan and Rob Pike called The Practice of Programming.
[00:00:20] It's a little hard to tell how many themes they had. One point they said three. By another account, I had seven. But in any case, they did have several themes, and the four most important ones were simplicity, generality, clarity and automation. And I quote from their epilogue, "Automation is underappreciated. It's much more effective to have a computer do your work than to do it by hand. We saw examples in testing and debugging and performance analysis and notably in writing code, where for the right problem, domain programs can create programs that would be hard for people to write."
[00:00:59] I think this is very, very true. Pretty much anyone, developer or not, kind of understands that computers are used to automate things. And yet for some reason, a large number of programmers who are very familiar with that and have done it many times find themselves doing the same repetitive work again and again and again, even though they have the skill to automate it. And obviously that's a bit of a lost opportunity. So, let's take a look at a few cases where automation is an option.
[00:01:30] We'll start with testing. Back when that book—The Practice of Programming—was written, testing wasn't usually automated. It was in some places—in large companies, large technical companies like Google, it probably was. But at most other places, testing was done by people manually entering whatever information or interacting with the app, whatever way they needed to to get to each branch of their code. And probably overlooking quite a few of them. Now that's a bit different. Now, most professional developers do automate their testing, at least to some degree. There are all kinds of arguments about how much should be automated and what sorts of things should be tested. But the idea of automating tests is both generally accepted and generally seen as a productivity win at this point.
[00:02:20] Another area where automation is now fairly common is deployment. Instead of going through a list of 20 or 30, some commands and tasks to be done each time code is deployed to the server. In many places it's just one or two commands and everything else is done for you, including running automated tests. I think until very recently, deployment automation was drastically undervalued and now it may be about right. I see some teams that don't automate anything and I've seen others that probably spend more time on automation that makes sense for very, very early projects. But on the whole, bigger teams all do it and should.
[00:03:02] Another area that's ripe for automation is performance analysis. And depending on what kind of development you're doing, that may be very easy. If you're doing web development, there's probably an off the shelf tool that can automate the analysis of your most important performance metrics.
[00:03:20] Now, I want to get into some things that people don't automate anywhere near as much as what makes sense. So, first one I'm gonna say is writing code. A lot of people write a lot of repetitive code and there are a lot of ways to automate that. Maybe the simplest is just using ed snippets. So you're using, say, Visual Studio Code or any really modern editor even a really old editor that's powerful like VI or Emacs, then you can type a few keystrokes that expand into a huge amount of boilerplate. And, you can even have variables that go into that boilerplate. The amount of time and the number of keystrokes you can save by setting these up is really pretty significant. Now, obviously, you're not going to define millions of editor snippet expansions, but I would say a good rule of thumb is if you find something that you frequently type that's reasonably long and varies in a reasonably predictive way, then make a snippet for it. An extreme form of this that's not in your editor would be generators like in popular frameworks such as Ruby on Rails, or Laravel or the Phoenix Framework.
[00:04:32] In each of those you can type a single line that will generate your model, your view, your controller, your template, whatever it's called in that framework, as well as database migrations and save you a lot of repetitive typing and possibly even some careless errors that you would have made. The next step up from that would probably be macros in functional languages. Macros will add new functionality to the language, new keywords to the language, and there really isn't much of a limit to what you can do. In fact, if you write a lot of macros, you'll end up with a DSL, which is a huge productivity win for a specific case.
[00:05:13] For example, writing string manipulation code in regex, instead of in Java, will save you weeks and probably actually get the task done. Of course, there are also some costs of writing a lot of macros or writing DSLs, so you have to be judicious about when to do it. In general, I'd say if it's a task that has to be done very frequently and the domain is tightly constrained, then a DSL makes a lot of sense.
[00:05:39] One example that I've given before was for my screencast site. So I've got many, many videos where I teach the Elixir programming language and for each one of those videos, there is a page on Alchemist Camp that displays that screencast And, some of them have notes about the screencast and links to source code and so on and so on. And in order to write those, I've made a modified version of markdown. It's got some extensions, so that certain things that I do a lot like embedding those source code snippets are automated and I can link to a specific time in the associated YouTube video with just a few keystrokes. And that's because it's a whole lot faster for me to have done this automation once in extending markdown a bit and writing the code to convert that into HTML, than it would be for me to type out an HTML <a> tag with href equals the URL for the YouTube video, with the appropriate query string parameters to give the timestamp that I wanted to link to... every single time I embed a YouTube video on my site.
[00:06:56] This is taking us a bit outside of normal dev work, so another place where people do a lot of automation is administrative tasks and this can be kind of a blurry line. A lot of this is actually, arguably your app. So one example is if someone needs a password reset, 99% of all apps automate this. Mine doesn't yet, but it will soon. And the reason it doesn't yet is because I've only had to do it three times ever. But over time, as you get more and more users than this is just so common that you you want to automate it.
[00:07:31] And there are other things you can automate that are administrative, like sending thank you emails to people after they've done certain things or telling, you know, telling someone what their progress is or linking to things that they might be interested in seeing based on their previous usage of your app or your site or your service.
[00:07:51] Marketing tasks can also be automated. We've got a lot of tools for automating Twitter like buffer meat, Edgar. So on and so on. And you can be sure that before these tools were created and sold to the market at large, there were a lot of companies that had already automated this internally so they could achieve more of their marketing goals with less time. The same is true for content. Content a little bit trickier to automate, but a lot of sites that compare two properties, or two stocks, or two options in a tech stack, do the same sort of thing. They've automatically generated who knows how many pages, basically a page for every possible pair of things that could be compared. And that brings in traffic, and SEO and so forth.
[00:08:40] And at this point, the trend is probably clear. I could go on listing another dozen sorts of tasks a programmer could automate, but it's a general ability. Pretty much anything on a computer that's done again and again and again, can be automated by a programmer. And I'm not saying everything that can be automated should be. Obviously, the costs, the benefits of doing so are different across different tasks. But in general, if something is time consuming or is done very, very often or needs to be done exactly the same way each time, or needs to be done very quickly in the case when emergency, say redeploying, then it makes a lot of sense to automate it.
[00:09:24] Conversely, if it's something that's done rarely, or something that's very easy to do, or something that's not urgent, then it is less important to automate that thing. As a rule, though, I'd say if you're a programmer and you find yourself spending a lot of time, doing the same tedious thing again and again and again, there's something wrong and you should automate it.
[00:09:47] Automation is one of the most important ways to get more leverage and get more done with the time, money and other resources you have. So, the principle of do not repeat yourself applies not just to your code, but to what you're doing. That's it for this time. And thanks for listening to Code and Bootstrapping.