DAVID: Hello and welcome to the Acima Development Podcast. We have got a full room today. We got people that are sitting in the back row lurking, and we got people sitting up in the front that want to hang out. So today, we've got Jason Loutensock, we've got Ramses Bateman, we've got Kyle Archer, we've got Zack Baker, Dominick Fabry, Eddy Lopez, Guillermo Barrera, and Mike Challis, and myself, David Brady. I will host today. 


And last episode, we talked about favorite tips, tricks, and tools. And we had so much fun doing that we're going to do it again, picking up from there. I know we had some fun pre-call chat about some really crazy stuff, things that you might not think about as development tools. Let's just open up the floor right off the bat. Does anybody have a development tip, trick, tool? 


I also...I had some people sneak in from the data team. I'm hoping more arrived. We've got Zack again. But I want to talk about how the data team thinks about things in a way that's very, very different than programmers. So I've kind of seeded the topic there a little bit. Does anybody have anything they want to do?


JASON: I actually just got introduced to a new tool yesterday. I was on a call with Matthew Rampey yesterday morning, another developer here. And it's a cool tool called Dash. I don't know how popular it is. And I can't actually remember offhand the name of the company that produces it. It's a place where you can download documentation for any topic, cheat sheet, stuff like that. And I added a shortcut, obviously, to my bash profile. 


So now whenever there's a command or gem I don't know about or some method in Ruby or Rails, if I'm not sure exactly what it does or I want to look at the documentation immediately, in the terminal, I can just Dash and then pass that in. And it's been super handy because immediately I get the documentation pulled out from a plethora of sources. But that's been my handy tool of the week that I thought would be fun to share.


DAVID: That is very cool. There's a system like that built into Ruby called ri, which is...I can't remember what it stands for. The r probably stands for Ruby. The i probably stands for info because I know Matts was really big about Emacs. Instead of using the man format, it uses the info format. The problem is the first versions of ri took a long time to compile. And so you would do like a bundle install to get all of your Ruby gems installed. 


And you would just see this compiling documentation for, compiling documentation for. So it kind of became a standard practice to do gem install, name of the gem, dash dash no ri, which means you would not have the documentation. And so we've now come full circle [laughs] to people going, oh, I don't have the documentation for all these things I installed without documentation. That's kind of cool. That's kind of fun. So you're using Dash. What are some of the things that you were able to pull up on that? I know that sounds like a really stupid question, but talking about the workflow --


JASON: No, no. Yeah, absolutely. So you download the app. And then you can manage a bunch of different dock sets. So they have a bunch that they support and kind of first party, if you will, of reports stuff. So you can have documentation for all sorts of things not limited to Ruby. You're not limited to Rails, everything, Python, whatever it may be, but you have this one source. And it's fully customizable. 


So if there are things that you're constantly referencing, if you're working around a data migration and you want to have all the documentation for ActiveRecord pulled up, there are cheat sheets for that if you wanted to do that, or I've got Git cheat sheets now. But I can immediately reference or pull those up straight out of the terminal. And, of course, it pulls up in the UI, which is slick. It's really nice. It's a lot of fun.


DAVID: That is very, very cool. I'm very happy to hear you say that it works for other things because if it was just for Ruby documentation, I was going to poke a little bit of fun at it because it's solving a problem we have created for ourselves. But, I mean, that's all of computer science. So we are the solution to and cause of all of our problems. But no, that sounds very, very cool. I will give that a checkout. What about ways of thinking? Is there an approach? Actually, let me turn this on its head. Is there a problem that you run into in your day-to-day work that you have recently found a solution that's very satisfying too?


MIKE: I am hesitant to jump in because I was hosting last week. 


DAVID: I'm glad you're here. Welcome, Mike.


MIKE: Last week, I just sang the praises of command-line tools because I think that they come over from the Unix world but are now in modern operating systems and are just unbelievably helpful. The ability to have simple, straightforward, single-purpose tools that you can chain together allows you to make an incredibly powerful pipeline, kind of on-demand, and just ad hoc. And that ability is hard to even describe how useful it is.


It's very easy to understate it. It is just fundamentally more powerful than anything else, specifically that chaining of tools because, otherwise, you have a single-purpose tool that can do what it can do, no matter how amazing it is; if it does that, you can chain tools together. You can come up with processes that their creators didn't even think about and novel things nobody's ever done before. That's amazingly powerful. 


DAVID: Yes. I liked the previous episode. You were talking about this bit. There's an idea that comes across in the Emacs camp called composability, where it's nice to have small, sharp tools. You guys talked last week about using awk, which is not a small tool. I mean, awk has its own programming language. And you can do crazy, crazy things just in awk. You can; I mean, it's got an entire language built into it. But it is super-duper-powerful. And there are lots of things. 


Nobody uses awk directly. You always take, you know, you use cat, and then you pipe it into sed, and then you pipe it into grep. And then you pipe it into awk from there to kind of present the report of the things that you want. And composability is this ability to chain things together or to tie them together. There is a text editor out called Sublime Text. And it's kind of a spiritual successor to an editor called TextMate, which was really popular about 10-15 years ago. 


And TextMate, I got really excited about it because you could put these plugins into it that were written in any language. It had, you know, well, not any, but there were a bunch of languages. And it supported Ruby, which is very, very cool. And if you register your little scriptlet with it, you click on the tools menu, and you could see that script, and you could click it, and it would run. And the problem is that it couldn't talk. That little scriptlet could not talk to any of the other scriptlets. They were siloed away from each other. 


So if you had a fragment of a command interpreter or a piece of something that did something useful, that, say, gave you fuzzy matching, you type amlmr, and the computer knows, oh, let's expand that to apps models lease management registrar. I don't know what the acronym is for. I literally just picked letters at random there. But that fuzzy finding, that expanding of the text to a string against a list of file names, you could do that in TextMate. And it was really cool. 


But if you wrote a scriptlet to do that, you could have another scriptlet, and it did not have access to that functionality. And this was like a first-order principle over in the Emacs camp. So there's literally like a fuzzy match thing, and it has no UI. It has nothing tied into it. It just accepts a list of things, a list of text strings, and you give it a fuzzy string match, and it returns the subset of things that matched it. 


And the person who wrote this published it along with a thing to find files on your hard drive using fuzzy matching. But as soon as they published it, somebody else said, "Oh, that is cool. I'm going to use that to let me fuzzy match and find variables inside the file." So all I have to do is collect all of the variable names in the current file and present them to this function that strips them out and puts them, so I can compose that function into my function. And you don't have to copy it and paste it into your library. You can just call that function remotely, and you can compose them together. And it's extremely powerful. 


It's just terrifically exciting to the point that I remember for six months just my head vibrating over the idea of composability as a development tip or trick of, like, hey, that's a cool algorithm you got there. But what would be even better is if you packaged it in something that could be shared somewhere else. I remember getting really, really...I was pretty insufferable there for, I mean, not that I ever stopped being insufferable. But at some point, I was aware that I was doing it, which is like peak insufferability.


MIKE: I'm with you completely on the composability. I think that that is the key attribute of, you know, the amazingness of that kind of tool. But it's a general principle. Command-line tools generally work that way, which makes them amazingly helpful. And the composability is just kind of central to their virtue.


DAVID: And to be clear, I'm talking about this from the Emacs camp. It's this first-order principle they bandy around. Vim does this too. It just does it in a wildly different way, especially the old school like the Vi before Vi Improved was kicking around. Vi was an editor that was supposed to be small and sharp. But they still had the notion of composability because they basically said, "No, no, it's the other way around. The editor is composed into the existing toolchain." 


So we were talking last week about our last episode about grep, and awk, and all these things. Well, Vim is just one of the things in that chain. And when you're in Vim, it's easy to make it so that a single keystroke will execute something at the command line, and there's no reason you can't pipe your entire file into it. So the ability to fuzzy match something in a file in Vim it's already pre-composed. You've already got grep on your operating system. Why would we build that into the text editor? 


All you guys that are in Vim composing hate mail that Emacs isn't that special, well, number one, yes, it is, but number two, you're special too. Vim can do everything Emacs can, except for the things that it can't because it doesn't think it should. This is what I was talking about, about design ideas and ways of thinking. Vim thinks a lot of things should be pushed out of it, or it used to. Vim has changed a lot in the last 5, 10, 15 years. 


But Vim used to just say there are things you can do in the text editor that you shouldn't. It's the job of the operating system to handle that. And Emacs, of course, everything should be done in-house. I'm fond of saying that Emacs is an operating system. It's a nearly complete operating system in and of itself. The only thing it lacks is a small, simple text editor.


MIKE: [laughs] That's an old one. I've ran into that one a few times before. But I think this is interesting. One thing we did not talk a lot about last week was kind of higher-level tools. Most of the tools we talked about were very low level like grep. We talked a lot about SQL or SQL, whatever you want to call it, [laughs] things that are kind of down at the bottom of the toolchain. 


We talked a little bit about much higher level tools but not a lot, things like, say, Kubernetes. And we didn't really dig into those. I think that it's somewhat telling that we all love our low-level tools because they're just so powerful. And just didn't talk a whole lot about anything that was much higher than that. 


But there are some high-level tools. Like I mentioned, we talked about Kubernetes a little bit, just a little bit at the end, or Docker, that are kind of at the other end from the command line that provide a useful utility up near the top of the stack. And those are also important tools. Kyle, I don't know if you want to talk at all about Kubernetes. You talked briefly about it last week. 


KYLE: Yeah, I can go off a little bit on Kubernetes just how it's kind of helped us here at the company just as a transitional thing. We used to run all of our services...I think it was Capistrano we used to deploy out. We ran on just straight EC2 VMs, which was working for us, and it worked really well. But we were able to migrate all the services over and get them running in Docker. And this allowed us to utilize orchestration tools like Rancher.


But building off of something like Rancher, we were able to go to Kubernetes. That tool has allowed us to cut costs in areas and share our infrastructure and get more services running per node than we were able to just on normal EC2 instances. This also allows us to get a lot of out-of-the-box features like monitoring or logging where we can grab everything from just a host, have all the logs just put on a host, and then have a log shipper taking those from that host and shipping them up to our ELK stack where we can visualize that.


Or we have Prometheus that's able to grab metrics. And it's able to use the Kubernetes Service discovery and ship all of those metrics that it's able to scrape from all of the services up to our Prometheus clusters. And, well, it ends up in Thanos but Prometheus, and we're able to visualize those in Grafana in each of our environments.


It's also allowed us to have certain tolerances on just normal hosts that we wouldn't have had, which is if a service is running out of memory or there's a crash in the app that's recoverable, Kubernetes is able to recover those services. It does these health checks every so often. And if those services go down, it's going to bring them back up. And it's going to continue to try and bring them back up, which was a hassle in the old way that we used to work. 


The management of it we're able to...I kind of talked about config management of some of this. Our Kubernetes clusters are in config management to where it's not per se a really easy task. But it has taken what could have been two-three weeks' worth of work to get an environment spun up, and that's down to a day or two. Just the speed and the flexibility that we have, we can replicate an environment, add more hosts, take hosts out with really with very much disruption.


We're even allowed to; in a couple of the environments, we're allowed to use Spot Instances, which is AWS' you can bid on instances that aren't being used in AWS that are EC2 instances and get them for lower costs for a certain amount of time until those resources are requested by another customer. In doing that, we're able to put those in our pre-flight in our development environment, or our dev environment as it's called for short, which ends up cutting our costs by a fourth or a third in those environments. 


The only problem there is every once in a while, we have hosts get taken out, but Kubernetes is able to handle that, spin up new hosts, and get our services running in those environments fast enough that there's little to no disruption at least as far as I've known. There have been a few issues. But it's one of those things where it's minutes of downtime in these non-production environments in order to cut costs down by a fourth. Kubernetes is very powerful in running infrastructure.


MIKE: It's really interesting when you started talking about Kubernetes, you mentioned seven other tools, which goes somewhat back to that composability. It sounds like part of what makes Kubernetes so useful is it allows you to connect to everything else in the ecosystem.


KYLE: Oh yeah. I'm trying to think of what tool we can't really connect to Kubernetes. It's just, I mean, it is an ecosystem in itself. You can put anything into it. You can integrate anything into it. You can run your servers in it, or you can connect to servers meaning like Postgres. You can run Postgres inside Kubernetes if you want to. You run it outside and have your infrastructure talk to it out there.


There are several tools to manage it. Like we've been talking about, you can use command-line tools to interact. There's kubectl to interact with Kubernetes. You can use GUIs. There's Lens. I'm trying to think of some other tools to visualize the tool and your ecosystem in there. And then there are different flavors I did throughout, like Rancher. Rancher has its own solution for Kubernetes. Then there's EKS which is AWS' solution to Kubernetes, which is what we use. And then Google has theirs. Everything plays a role in Kubernetes. 


DAVID: That was exactly the comment I was going to make was that you started talking about Kubernetes, and you immediately started throwing out ELK, and Prometheus, and Thanos, and all these other Greek deities. And I guess ELK wasn't one, but, yeah, the idea that it ties you into these other things.


That actually reminds me of a thing that was in the discussion last week. Mike, you guys talked about IDEs versus command line. And I used to be super into IDEs. I was a big, big fan of Developer Studio, which was kind of the precursor to or the spiritual ancestor to VS Code these days. It was the big Microsoft flagship tool. And the thing that I loved about that was that you could do anything. 


And I got to the point where I was scripting my own stuff in VBA, which is Visual Basic for Applications. I could write things that would put buttons on the toolbar that I could click that would run things. And it was very cool and very powerful and very exciting. But it was very hard for me to test anything that I had put in the IDE because in order to operate an IDE, you need a human being. 


And when I came to that IDE, that was the feature that I wanted was that the IDE came up, and it just presented a smorgasbord of click on this button or this menu item. You can do anything that you want to do in your application. You just drag it and drop it and move it around from here to here to here. Whereas the command line it just presents you to the prompt and then asks you what do you want to do? And, I don't know, give me some ideas. Can you give me some guidance? And the command line is like, no, what do you want to do? It's just this blinking cursor. 


But once you figure out what you want to do in the command line, you can script it and automate it very, very quickly and very easy, and you can chain them together. And these days, instead of an IDE, what I have is a folder called bin, which has all my binary scripts that I run, and it's up on GitHub. And every time I get a new machine, I pull that collection of scripts down. And this gives me basically like a set of wrappers around all my git commands.


I make it very easy. I have a git script called gob, which is go branch. And when I type gob, the command line pops open a little...this goes back to the composability thing as well because it uses a tool called Selector, which does fuzzy matching in bash. And so I type gob and, boop, it presents me a list of all the branches that I have checked out on my machine. 


And I can start typing part of a branch name, and Selector will pick it. And then I hit Enter, and then it feeds that back into the git checkout command. And then it checks out that branch. And so it makes it really easy to do that from the command line. And I've added that IDE navigability back into the command line for myself. 


I will not lie; writing a bin folder for myself has been a project that has been ongoing for 15 years. And it's very complicated. And I've had people laugh at how complicated my scripts get because I'll end up writing a script that is nothing but the help for the other scripts. And that's because I write a script, and then I immediately forget how to use it, which is intentional. I don't want to be using brain cells to remember all these dozens and dozens, if not hundreds, of scripts that I keep on my system that are all operated differently. 


So I literally will write a help script. Maybe that's a meta development trick is that I work very, very hard to have nothing that I have to memorize before I can operate some software. So anytime I write something, the first thing I have to do is the software will introduce itself and tell me how to operate that software. And that makes it so that I don't have to remember how any of my scripts work because if I try to run them and I run them wrong, the script will stop and say, "Yeah, here's my help info."


MATT: I think, as engineers, that's kind of our M.O. Our whole purpose is to create things that take out the human interaction. And I've always said I'm an engineer because I'm lazy. I want to create things that do other things for me.


DAVID: Lazy with a capital L though, right? Because you will work all day. You'll stay up...this is something my father-in-law used to say, "You'll stay up all night trying to figure out how to get out of an hour of work.


MATT: 100%. 


DAVID: And he meant that as an insult, but I absolutely took it as a compliment of, like, oh, you better believe it. You better believe it. Because that hour of work I have to do every single day, once I spend that all-nighter solving that, I never have to pay that hour again for the rest of my life. And I also never have to pay the all-nighter again.


MATT: It's all about the end game.


MIKE: This reminds me of something that I was really struck by. I read it a couple of years ago. And, presumably, it's still true. It said that at Microsoft, part of what's led to their kind of rebirth as a company and getting back and being a leading company again is that they have a rule within the company that if they have a choice between working on a feature and working on something that improves developer productivity, the rule is choose the thing that improves developer productivity. 


DAVID: Wow.


MATT: I think that's a great policy. In the end, those features are going to benefit from that. You may front load a little bit of extra work, but in the end, it's going to save you time over time with multiple features versus just getting a single feature out quickly. And I think companies who have that mindset highly benefit.


MIKE: It's got to snowball. As you make developers more productive, they do things to make themselves more productive and more so and more so over time. And you just become kind of a juggernaut [laughs] of productivity rather than just gradually become less and less capable, which is going to be the default because entropy just makes everything fall into disorder and decay.


MATT: Yep. That whole work smarter, not harder mentality, right? 


MIKE: Yeah.


DAVID: There is a fantastic xkcd. It's number 1205 for those of you playing along at home xkcd.com/1205. It's called "Is It Worth the Time?" And it is a chart of how long you can work on something to make it faster, better, and easier. And it's a chart of, like, how much time did you shave off this task multiplied by how often do you use this task? And the chart points to how long you can work on this problem before it stops being useful. 


Like, people realize that, oh, I did this thing that shaves 30 seconds off of a task. Well, that's cool. How often do you run this task? Oh, once a year. Okay. Well, according to the chart, if you spent more than two minutes working on speeding this up, you've actually taken more time. You've not done lazy with a capital L. You've just done regular lazy with a capital ADHD. You got distracted and went down the rat hole.


But if you have a task that you do three times a day and you figure out how to shave one second off of it, if you spend all day on it, it pays off. It's worth it in the end run. Because over four or five years, that stacks up, and eventually, you're saving more time than you pay. You figure out how to shave 5 minutes off a task you run 50 times a day; you can work on this for nine months before you have sunk too much into it. So yeah, lazy with a capital L. It's a good idea.


MATT: All about ROI. 


DAVID: Yes.


MIKE: We're sometimes hesitant to put in that I [laughs] to get the R.


MATT: Right, right. Absolutely. And I think business is scared of things like tech debt. They think, well, is focusing on this tech debt going to increase profitability? And, I mean, ultimately, the answer is usually yes, but it's very hard to visualize.


DAVID: I spoke at a conference a couple of years ago, and I talked about how ROI on refactoring is usually worth it. But it's not going to pay off this sprint. And I think a lot of...I'm going to say team leads and managers but I'm not saying this is a culture or flaw of them. I mean, somebody in that position has some necessarily short-term focus. Sometimes we think if you pay attention to the pennies, the dollars will take care of themselves. 


So if you focus on making each sprint go faster or each week of development just eke me out just one more story point out of the team velocity, well, then, in the long run, everything goes faster. And when we think about deep ROI, this does not apply. You absolutely end up getting trapped into kind of a local maximum problem where in order to go further up the hill, you have to go down the slope that you're in. 


I grew up in mountainous rocky canyon-y territory where the terrain was divvied up into fins of sandstone. And often to get to the top of the next fin, you had to jump down off the fin you were on. That's kind of a local maximum. And your manager wants to get as high up the rock as possible. And your manager's time frame is only long enough for you to take 20 steps because it's just this sprint, just a sprint, just a sprint. 


And so your manager doesn't want to climb down off this fin because you're going to lose height, you're going to lose height, you're going to lose height. Well, yeah, I have to because I want to get up that fin, which is twice as high as this fin. Does that make sense? You have to put that investment and you lose the return instantly. The investment is the reverse of return. You're paying out on the thing that you're going to get back. 


MATT: We're talking about these tools, right?


DAVID: Mm-hmm. 


MATT: And for anyone who is new to this industry, I highly recommend focusing on the tool that is you, not that you're a tool.


DAVID: Oooh. [laughs]


MATT: Not that you're a tool. But we talk about all these physical tools like Vim. And I am a JetBrains user, whatever. But if you can focus on these tools, and learn how to approach these problems, and learn how to have a little bit of foresight on what you are doing, in the end, that is a tool that is going to save you time. It's going to help the company save money and make money, and it's worth the investment.


MIKE: Brilliantly put. Here at Acima, the management has often said that we need to take some time to sharpen the saw. And that saw they're talking about sharpening is your own...is that tool yourself that you're talking about. And a lot of people have set aside time every day to take some time to sharpen that saw, and I think that the payoff has been tremendous. What you said there is brilliant that you're the most important tool. I'm guessing that other people have some things to say about that because it was so on point. 


DAVID: There's a thought that came immediately to my mind, just an epiphany that I had when I was on your team, Mike. The Atlas team does a Skills Clinic every day where we just focus on getting better at something by working on an unrelated problem and throwing weird approaches to it. And there have been times in Skills Clinic where people have been like, "Oh, we got to focus on this thing because we got to get this done." And I kind of jumped in and said, "No, you don't have to get this done." 


I mean, getting things done is a skill, and there's a time and a place to focus on that. But Skills Clinic, we look at programming so much as like you take a problem. You give it to a programmer, and that programmer outputs a solution. It's almost like a function. This function takes a problem as an input entity, emits a solution as an output. But Skills Clinic takes the approach of no, no, we take a problem and a programmer as input. And what we emit is a solution and a better programmer. 


And that is a huge epiphany that I've realized that that kind of thinking will absolutely make your career if you view every problem you approach as yourself being the input and output of this problem. Sometimes, you want to just jump in and solve the problem the quickest, fastest, easiest way. You want to optimize for minimum investment to get that maximized return. 


And other times, you want to focus on developing yourself, make yourself the inputs to the improvement process so that when you come out of it, you're like, okay, well, that took twice as long as I really wanted it to. But now I know Kubernetes, or now I know Terraform, or now I know the ELK stack, or now I know how Grafana works from inside Ruby or Python, that sort of thing. Huge shift in the mentality.


MATT: Right. Regurgitation is easy. But it doesn't provide a whole lot of value for yourself or for your employers in the grand scheme of things and in the --


DAVID: In the short term, it does, though, right?


MATT: 100%.


DAVID: The things that you can just regurgitate on demand right now are the result of the investment. That is the return on the investment that you paid into three sprints ago or two years ago. And completely weird 10-second story; I went down the rathole years back, and I learned to program in Lua, which is just a weird scripting language nobody ever uses. 


So when I got into Lua, it was out of Brazil, so all the documentation was in Portuguese. And I'm like, oh boy, this is head-hurty. And 5, 10 years later, I needed to write a Read/Write Splitter in MySQL, which is, you know, I don't want to start a database war, but it's a database; we'll put it that way. It's a database. And there are a lot of databases that like to look down their noses at MySQL. 


And at the time, MySQL had absolutely no concept of middleware, and no concept of Read/Write splitting. And then somebody said, "Well, there's this middleware layer that you can install for MySQL. The problem is it's only scriptable in some language called Lua. Does anybody know this?" And I'm sitting there going, oh, oh, oh, because I never expected this to pay off. But here we are.


MIKE: To be fair, I think Lua is used in a lot of embedded systems, and that's where it shines, and that's its purpose.


DAVID: It's what it was designed for was you could drop Lua into a C++ program, and now people can script your C++ code at runtime from a text prompt. That's exactly what it was for.


SPEAKER 1: Adobe uses it for things like Lightroom and Photoshop plugins.


DAVID: There's a really big game that got scripted almost entirely...and I want to say World of Warcraft. Don't quote me on that. I didn't play a lot of WoW. But there were a lot of people around 2010, 2009 timeframe who were not programmers that knew how to script in Lua because there was a really popular game out at the time that was scriptable from Lua. 


And they didn't advertise that it was Lua. They were just like, oh yeah, you can script our game. Here's the manual to our game. And then somebody finally went, wait a minute, this is Lua. And they started manipulating the vector tables that you could pass around. And it worked because it really was Lua.


JASON: My nephew, my 11-year-old nephew, who wanted to get into programming in general, got into a game called Roblox. And that's, I guess, massively popular now. It's the same idea that he's learned to script in Lua. It's really fun.


MATT: You have Minecraft. I mean, things like that are really pushing these youngsters to learn this stuff, and that's great.


MIKE: Which is a great segue into our next episode. [laughs] We're just going to be talking about how to teach your kids to program. 


SPEAKER 1: One topic that we've kind of talked about but on a higher level, I'm kind of thinking about it with everything that's been said, is just kind of automation in general. As an engineer, we're all wanting to use different tools, and we're all wanting to make our jobs faster and get on to the new shiny per se. And I'm just thinking about it, and I feel like one of the biggest things that we can do is anything that we're finding that's just repetitive, that is old, and that we're just not really wanting to personally manage all the time we need to take the time to just automate that. 


And it kind of goes back to the ROI conversation. It might take you a little bit longer to automate that task than to just go click through it or whatever you happen to be doing. But there's going to be a huge benefit to getting it automated because, yeah, it took you 15 minutes today when it normally takes you 30 seconds. But if you're doing that daily, weekly, or whatever, that's going to save you a lot of time and money. And then you get to work on the next task that's caught your interest or the next framework, whatever it is that you happen to be working with. 


It made me think back when we were talking about setting up your machine. I ended up working with a guy that was specific in the Microsoft world, had been for years about 13 years of C# experience. And using Windows, one thing that was never really pushed for me was the command line or PowerShell. In Windows, everything has a UI, has a GUI. So it was kind of a foreign idea getting in and learning about package managers and terminals with Linux. And I thought it was really cool. 


And he ended up showing me one day he has his entire Windows setup in a PowerShell script. He used an open-source package manager, Chocolatey. I think there are better ones now. But he would set up his entire development environment, even for Windows. And this was even a few years ago. But my main point is just automation and automating everything because, as engineers, we don't want to do the same task over and over.


SPEAKER 2: David, you were asking for difference in thought processes. And I would say this is probably the biggest similarity. I think all around software engineering, data engineering, DevOps, everywhere, we don't feel like, or at least my feeling on it, I should say, I want to automate myself out of a job, basically. My job is not done until I've done that. So automation any tool I can build to automate something.


DAVID: There's a fantastic joke that a boss of mine told me years and years ago. This guy comes into work, and every day he comes into work, there's this guy sitting in an office, and he's just kicked back with his feet up on the desk, and he's just staring out the window. And he's never doing any work. He's just constantly staring out the window. And this guy, he sees him every time. 


And finally, he gets frustrated. And he's like, "Who's that guy that's never doing any work?" And his manager says, "Oh, that's Bob. Last year, Bob came up with an idea that saved the company $20 million. So Bob's job now is to sit in that office and come up with another idea."


MATT: Yeah, I think we're a long way from working ourselves out of a job. You know, even with artificial intelligence and everything, there's always going to be a need for someone to help create and scale that type of thing.


SPEAKER 2: Yeah, I wasn't saying that we're close. I was just saying that's the goal. It's a very, very far distant goal that may never be realized. But as you build these automations and do all this stuff, like data engineering, for instance, we could just have somebody go into all these systems and copy-paste all this data into a CSV and then go into DataGrip and say, "Here's a CSV," upload this to a table. But we're automating jobs out, essentially. It's in the best of our abilities. So that's all I was stating with that is like the goal, which may never be achievable, but the goal would be automation.


MATT: It's a good goal to work for. I would love to be good enough to work myself out of my job.


DAVID: But it won't happen, though, because --


MATT: But it will never happen.


DAVID: But it also will happen. Because what will happen is I talked a little bit earlier in the call about how I've got this gigantic folder called bin, and it's got all these scripts. I have worked myself out of the job of managing git from the command line because I have this suite of scripts that will check out branches that will...I can run this pattern-matching thing to delete branches off of my machine by Jira ticket number and that sort of thing. And I got all these scripts to do this. If you are constantly working yourself out of a job, you will find yourself managing batches of those jobs that you have worked yourself out of. 


And I'm saying this like I'm a really smart person. If you could see me in person, you'd realize I'm just vibrating in my chair because this is something I just realized talking to you guys in this call just now is that, yeah, if you focus on improving your skills and trying to work yourself out of a job, you will wind up with so much more capacity because now you can spend your time thinking about, well, now that I've got all these jobs solved, what can I do with all those solutions in my back pocket? You know, with all those arrows in my quiver, what kind of bigger game can I hunt now?


MATT: You're making yourself much more valuable.


JASON: It's just like the pre-industrial revolution. Everybody was working 100-hour weeks doing some monotonous task. As soon as you automate it, you go from 100 to 40. And now everybody as a whole has more time to invest in new creative solutions and coming up with new ideas, so exactly what you're saying, opening up yourself for a greater capacity, just leads to a new revolution.


MATT: Yeah, it drives innovation.


MIKE: I was going to say the exact same thing, Jason, that Industrial Revolution didn't get everybody out of a job. It gave us modern civilization.


DAVID: And created managerial jobs and labor management jobs for the people that had been working on grinding wheat.


MIKE: It's exactly right. It allows you to do higher-order work that is probably more rewarding and way more productive.


SPEAKER 3: If you're willing to be flexible, you're not really automating yourself out of a job. You're just automating yourself into a different job. 


DAVID: That is a beautiful way to put it.


MATT: And a more fulfilling job.


DAVID: I can't think of a better way of summing up the topic for this episode and the previous one that the whole point of all these developer tips and tricks is that you're automating yourself into a better job. And it doesn't necessarily mean leaving your current employment. It literally just means you're increasing your capacity and your ability to handle more responsibility, which is awesome.


MATT: Moral of the story is sharpen the tool that is you.


JASON: I just have to add that Acima, as a whole, has been incredible; not to go all corporate or whatever, but it's been incredible that this has been prioritized in a way. And, for instance, our Skills Clinic that we do that you've touched on before, I've learned more in that Skills Clinic than anywhere else given the same amount of time. It's phenomenal. And I always walk away applying those new things that we got to investigate and learn that were completely unrelated to my everyday work. So I just wanted to touch on that culture and how grateful I am for it. 


MIKE: And that can be repeated. I'm assuming that we have listeners that are not [laughs] working here. That's kind of the point, propose this or implement it. Better than propose it, make it happen at the place that you're working, and things will go better. [laughs] It's on you now. You've been given a choice. Are you going to take it, or are you not? You have the opportunity to go out and sharpen that saw. There's a strong invitation here that it's worth it and you should try it. Pick up that file, start sharpening.


MATT: I would highly recommend always try and gravitate towards people who have better skills than you and people who are better than you at what you do. That is the way to grow.


DAVID: The most biggest growth I ever had was I was the only guy on an engineering team at Evans & Sutherland, which is a big graphics company in Salt Lake City. I was the only kid on a team of 26 who did not have a master's degree or a Ph.D. And I dropped out of college. So I was like two full schools behind [laughs] everyone else on my team. And it was drinking from the firehose every single day. I was ten times the programmer every year than I was before. It was amazing.


MATT: Yeah, you just have to swallow that pride and take it all in.


DAVID: I will throw this one in as well. I worked with a programmer years and years and years ago who was super arrogant and obnoxious, and he had to blow his own horn all the time. Anyway, he was kind of insufferable to be around. And I realized he's this way because he's insecure, and I don't like it because I'm insecure. It was very much like some one-upmanship, or I'm smarter than you, that kind of thing. 


And then one day, I realized, six months from now, I'm going to know everything he knows because he can't stop himself from telling me how smart he is and how he does this thing and then showing me how to do it, which I realized was actually super valuable. And I realized six months from now, I'm going to know everything you know, and you're not going to know anything I know. I'm content with this arrangement. And I was able to remove my ego from the problem. And it turned out that I was right. He was actually an invaluable training resource to me, even though we were both college-aged kids with just awful nerd personalities that were absolutely insufferable. 


SPEAKER 3: You know, Dave, I kind of want to echo what Matt said, where put yourself in an uncomfortable position in a sense and reach out to developers in a way that you will pair with people more. When I started, and it's like you said, I was drinking from a firehose, but I quickly realized that the more time I reached out to someone for assistance, the quicker I learned, so my growth has grown exponentially because of the help that I received from people.


MATT: And I feel like, at Acima, we've built a really good group of people for that. We don't know what we don't know. But we have such great people and such a great team. Everyone has something to offer, and if we can all realize that, we can all learn and grow together.


DAVID: Take some time in your office and be Bob, right? Try to come up with an idea. And spend some time actively trying to come up with ideas. Your ability to come up with ideas will improve directly as a result. 


All righty, we are at time for the hour. I kind of call this the podcasting phenomenon where you start the call, and it's a little bit dry, and nobody has stuff. And then some ideas will happen, and we get sparked on them, and we riff on them. And you get to the end of the hour, and everybody's like, oh, one last thought, one last thought. I love that. It makes me very, very happy to have that. 


And I want to thank everybody that came today: Jason, and Ramses, and Zack, Kyle, Michael, and Eddy, Guillermo, Mike, Matt, and, oh, [inaudible 43:18] came in a little bit late. Sorry I didn't introduce you, but happy to have you here. Thanks, everybody, for dropping in on the call today. We will see you guys in the next episode.