Acima Development

Why do you use or why do you not use Ruby?

Transcript:

MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I'll be hosting again this week. We have with us: Matt, Eddy, Kyle, and Ramses. And I hope to hear lots from them today.

Our topic is going to be about the Ruby programming language and, specifically, why or why you might not want to use Ruby. This is maybe an interesting time to be talking about that. To give a little bit of history of the Ruby programming language, it's been around since 1995 or so. The creator goes by Matz. He's from Japan. And Ruby was very popular originally in Japan. It was one of the few languages that was documented well in Japanese and became extremely popular in Japan. It wasn't so very popular outside of Japan. I'll get to the moment that changed in a moment.

Ruby is an interesting language. It was inspired by a couple of languages, in particular, maybe most pointedly Perl and Smalltalk. Perl being a scripting language primarily used in shell scripts but also used a lot in the early web, and that is wildly flexible. If anybody has ever used Perl, reading Perl code is not for the faint of heart, but it's exceptionally powerful. And the people who use it tend to love it. And that was a lot of the inspiration for Ruby. So Ruby is very good at text parsing and doing the kinds of things you'd want to run scripts in the shell for.

Ruby was also heavily inspired by object-oriented languages, not necessarily the ones you might think of like Java, but Smalltalk, which is deeply, deeply object-oriented. Ruby is more object-oriented [laughs] than most object-oriented things in that it doesn't even have what you typically think of as primitives. You can call methods on integers. You can call methods on strings, their objects, just like anything else is an object. Really, anything is an object you can call. You can call methods on methods. [chuckles] It's deeply object-oriented.

But, on the flip side, it's also a deeply functional language in that every line is an expression. And it borrows a lot from functional languages as well. You don't ever see for loops in Ruby because idiomatic Ruby doesn't use that kind of approach, that kind of procedural approach. We use iteration and pass anonymous functions. It's got a special syntax for anonymous functions. So it's both deeply functional and deeply object-oriented and very good at text parsing. It's kind of an interesting language that allows you to do a lot of different things rather than necessarily having one way to do everything.

So that was around 1995, Ruby was created. About ten years later, in 2005, there was a big change in web development. There was a new framework that came out called Ruby on Rails. And, at the time, in web development (I was out there at the time. [chuckles]), web development was pretty clunky. There was a lot of boilerplate you had to set up. There was vast amounts of configuration files.

In the Java world, you'd set up a lot of configuration in, like, XML files before you could do anything. In the other interpreted languages like PHP, there was...really kind of fast and loose. People would do a lot of things without much protection, and there were a lot of security problems. By default, there were a lot of problems with unsanitized database access. And as a result, there were a lot of security breaches. So over on the scripting side, a lot of mess, over on the kind of big enterprise side, very difficult to use.

And Ruby on Rails came out, kind of bridging the world between those two. And it was written in a scripting language, giving you the ease of use of a scripting language and the quickness. Using an interpreted language, you tend to go faster with some of the structure that you'd get in the big enterprisey sort of frameworks. And it followed a lot of best practices, such as convention over configuration, so a lot of that boilerplate just went away. And it had a huge impact. Most of the web frameworks today are heavily inspired by Rails, even if they don't exactly follow what Rails did at the time.

Now, we are getting close to 20 years after that, and, you know, the world has moved on. Ruby on Rails is still around, but it's no longer the, you know, the top dog. I did a little research this morning, and JavaScript frameworks have absolutely taken over both on the client side and on the server side. We've got a world where there are client-side frameworks like React that dominate. And on the server side, JavaScript has largely stepped up as well. The most popular server-side frameworks are also written in JavaScript, well, with Node.js.

Python, which is a similar kind of language to Ruby, is also quite popular on the server side, and PHP is still kicking around too. You got frameworks like Laravel. The world has changed. Ruby on Rails inspired a lot of other frameworks, but itself has continued to evolve or maybe hasn't evolved as much as some of the others, which brings us to today. Our question is, why might you or might you not use Ruby today?

I want to share one anecdote of when I started using Rails myself. I started using Rails in 2005, the year it came out in beta. I was a Java developer at the time. And I first saw a presentation at a Java users group about Ruby on Rails. And I thought, ah-ah, I could do any of that in Java. [laughs] I honestly wasn't very impressed when I first heard about it.

And then, I got pressured by the company I was working at at the time to switch over to a scripting language. They were pushing for PHP. And I'd seen the kind of lack of structure at the time, and I was very resistant to kind of going into that Wild West that was out there at the time. But I thought, you know what? I'm going to try this new framework I heard about, Ruby on Rails. I learned the language and wrote a prototype over a weekend. I kind of devoted my weekend to it, which says something.

I was able to learn the framework and write a prototype of the app we were in over the weekend. We built out that app. And within a few months, we had rewritten our primary app in 1/10th the lines of code. There was literally 1/10th of the lines of code, even as we'd continued to add features. So the application could do more with a tenth lines of code as we had in Java because it's so much terser, and so much boilerplate was removed. I was impressed and kind of in love, [laughs] to be honest. It was so nice.

And I've been doing mostly Rails in the years since, and I've seen some good and bad. I can speak a lot to that. As to whether I'd start a new project in Rails today, I very well might. It'd depend on what I would do. If I wanted to do a very traditional web application, maybe with fast prototyping, I'd almost certainly go with Rails. If I wanted to do something new that had a heavy front end, I might use Rails on the back end because it's still a fantastic back end. But it's a good chance I'd use a JavaScript front end and not use what Rails provides for the front end.

So if I were to share my opinion at a really high level of some things I might do, that's what I'd share. For anybody who's considering using Ruby, it's nice to know some of the history. I'm interested in what other people think about where Ruby and Rails are today (Rails has really dominated Ruby development since it came out) and whether or not you'd use it in a new project. Any thoughts, anyone?

EDDY: I went ahead and looked up at the top languages or stack of 2022. This one's particularly the most popular programming, scripting, and markup languages found from Stack Overflow. And to kind of reinforce what you were saying, JavaScript came in at 65%.

MIKE: Wow.

EDDY: Which is a huge chunk, right? And then dwindling down from that, you have HTML, CSS, SQL, Python, TypeScript, and all the way in the bottom 6% of those were Ruby. So it kind of just gives me the impression, you know, that the hype train for Ruby has dwindled quite a bit over the years. And this is just judging off of the 2022 statistics. It begs the question, I guess, the context being why or why not Ruby? Well, I guess you could debate, based off this chart, that for job security potential or stuff like that, maybe Ruby was not a bad choice. But, again, I guess it just depends on what you're really aiming for.

MIKE: Yeah, popularity is an interesting metric because if it's highly popular, there's probably a lot of jobs available. That doesn't necessarily mean those are the best-paying jobs. [laughs] Ruby developers have generally been relatively well paid, I think because they tend to be able to do more with less. You get a lot done; it makes you more valuable. But if you can't find any developers, well, then the company is not going to hire Ruby developers, and the market collapses, and then your value as a Ruby developer just disappears anyway.

And there's a balance there, you know, 6% is still some. There's still a decent Ruby market out there. I mean, there's millions of websites out there. There are still large enterprise-y applications out there on Ruby on Rails, such as Shopify or GitHub. So, you know, there's still a vibrant Ruby ecosystem out there. But, to your point, 6% is not 60%. It's ten times smaller than the JavaScript world out there.

EDDY: I'm hoping you can kind of elaborate on that a little bit on why it's gone down. Is it just because it's an old language and, you know, loud voices get more attention? You know, so, like, JavaScript will get more popularity since you have different frameworks. Python and TypeScript is the new thing. So I'm just curious on, like, what has attributed to the popularity?

MATT: Like Mike, you and I have a very similar past in our career path and the languages that we've written in. Engineers, in general, have a tendency to jump on the hype trains, and we see things that are new and shiny. And because of the way our minds work, we're very curious, so we like to try new things. That's one of the reasons I think that JavaScript has taken so much traction because, you know, we spent all of these years only using it on the front end. And now that we can use it on the back end, it's like, oh my gosh, I can use everything in my application in one language.

But, you know, you'll find that front end and back end are very different, especially if you're using TypeScript and things like that. I personally am not ready for the JavaScript back-end world. I don't feel like there's enough structure yet. There are a few frameworks, things like NestJs, that help with that. But just coming from someone who was strictly JavaScript, it makes codebases extremely hard to work in when people don't establish consistent patterns. And that's something that I really love about Rails.

You know, there are definitely different ways of doing things with Rails. However, I think, for the most part, you're going to find a handful of patterns that get followed. I don't mean structurally as far as your code organization and things like that, but I mean the way your code is written. Ruby and Rails are very, very easy to follow and, like Mike said, very fast, and you can get a lot done with very little. And for that reason, I absolutely would use Rails for a back-end system today.

And again, like Mike said, I would use a JavaScript framework for the front end because you can definitely get more done that way. But that's kind of my opinion, you know, coming from, historically, I started out writing conversion code, converting COBOL scripts to Perl and PHP. Talk about a nightmare. And you really quickly see how loose and fast PHP could be as well. But, again, it was loose, and back then, everything was procedural. I think we yearn for some structure and some organization in our code.

MIKE: You know, you asked, Eddy, why people might be jumping on the new thing. I think that there is, you know, that hype that draws people. I think that's part of why people got on the Rails bandwagon in the first place as well, you know because you get some hype. People want to kind of be with the popular thing. And that's something hard to escape in human nature. But I think it's a bit more than that as well.

But somewhat related, if you're going to be writing a big JavaScript front end, you're spending day in day out in JavaScript, and then you have to write a different language on the back end. That's a little challenging that you have to think in two different ways. If you can write in the same language on the front and the back end, you avoid some of that.

Now, I agree with Matt that they're pretty different between the front and the back end. And the back-end frameworks are not the same as the front-end frameworks. My experience thus far has been, yeah, they don't provide as much structure as I would like to have. And they tend to degrade into a mess without a lot of diligence and care from the developers, which sometimes is hard to maintain over a large group of developers in the company. There's some risk there.

But not having to change languages is a real bonus. And a lot of people have gone with that since JavaScript is the only option on the front end, and you're having to do JavaScript. People think, well, why not just also do JavaScript on the back end? You know, that's kind of a compelling argument, especially for a smaller application, a smaller back end. It's convincing to a lot of people.

There's also been the rise of Python, which is a similar language to Ruby. I'm not going to say they're identical. They have somewhat different takes on things, but they kind of fall into the same space. And Python has gotten very popular in the machine learning community, and where machine learning has been under such a big boom in the last few years. Now you have another language that a lot of people are using, and they don't necessarily want to learn something else to go into web development.

So, if you're already doing a lot of machine learning, you're likely going to be using Python and using a Python framework, again, just so you don't have to have two different things that you're doing. And I think that there's a lot of that as well; people just want to use the same tool that they've been using. So, if you're doing a lot of heavy JavaScript front end, it's likely you're going to do some on the back end. If you're going to be doing a lot of heavy machine learning-type work, you're probably going to use Python because that's what you're already familiar with.

Kyle, I'm interested from your perspective because you're over on the DevOps side, and you use a lot of different kinds of tools. And you've probably seen some of this, like, oh, I've gotten used to this tool, so I'm going to use more of it for this, or [chuckles] maybe you use so many tools that you're just, like, whatever fits in the moment.

KYLE: We're kind of a bit of a mix. We kind of started out as the team was growing. And I came with more of a Python background. My manager came with a Ruby background. And then my team lead; he had more of a Bash background for all the scripting that, you know, that we're doing. And that has kind of mixed as we've done things. And so when I've written monitoring tools, that's been in Python just because it's been familiar to me. And when backup jobs and stuff like that have been written, those have been in Bash because that's what was familiar to my team lead.

However, a lot of the other stuff was by our manager, and he was familiar with Ruby. So him and I go back and forth on that because there is a little bit of a competition between Python and Ruby, just at least in our team and, you know, which one's the better language. It's mostly a joke than anything anymore because, well, I do like Python. And I could do the same things that I do in Ruby in Python.

I've actually adopted and started writing a lot of our Terraform generators, is what we call them, using ERB just because the ERB option with Ruby is just so friendly to me, at least, to where I can just put a little bit of Ruby code into the ERB to help with the generation. And when I'm saying generation, we're creating little Ruby apps to generate our HCL code for our Terraform. We have quite a bit of that just to get our automation done. And that's just been easier to do than deviating to Python or something, as well as when we have been working with services in the teams because we do have Ruby developers here.

It's really nice in our environment because we do work cross-services; not all the services are on the same version. And it's RVM, I believe, just feels so fleshed out to me. It's just really easy to set up those virtual environments. And maybe it's just the way I use it, but I haven't had that ease of a virtual environment. With Python, I tend to have issues here and there. Whereas RVM, I've hardly ever had any issues. So that's been really nice on the Ruby perspective.

It's also been good...we have a tool called [inaudible 16:45], which is an internal tool which does wrap a lot of the more common CLIs like the AWS CLI and stuff. A proof of concept for that just to see how it'd work out that was written in Ruby, just because it was easier and faster to get it done. To solidify it to where it was, you know, cross-platform that ended up being written in Golang. But to get a proof of concept going Ruby is just really easy to kind of get those things done. It's really easy to get scripting, really easy to get templates going.

MIKE: And there are quite a few systems, DevOps tools that are written in Ruby. Are there not? You mentioned the ability to do ERB scripts with Terraform. And I haven't been much on the DevOps side for a long time. But I know that I will occasionally see this tool, like, oh, that's written in Ruby.

KYLE: You know, you say that, and nothing's coming to mind right now. I'm only thinking of the Python ones, but yeah, there are definitely some Ruby ones. I just have to think a bit harder.

MIKE: Yeah, I know that there are a few of them. And maybe they fall out of, again, with the hype cycle. Puppet is written in Chef or written in Ruby; it looks like. And it may have been slipping somewhat out of popularity. I'd have to go dig because I don't have a lot of expertise in there.

KYLE: Yeah. Puppet they have competition from other ones like Ansible, and Ansible is what we use.

MIKE: So that, yeah, that's interesting. So you end up using a lot of tools. You like Ruby, but there's other tools that can also get the job done. [laughs] And the best tool for the job, it sounds like.

MATT: I firmly believe that teams should use the best tool for the job. One of the things I forgot to mention, though, with Ruby and Rails is you can really ramp up new engineers very quickly with Ruby, and I found probably more quickly than with most other languages. If they have any experience in other languages and understand basic programming principles, Ruby is really easy to pick up.

MIKE: I think there's a lot of truth to that. I might ask Ramses. You've been doing software development for a few years now. [laughs] What are your thoughts about learning Ruby as a primary language?

RAMSES: Yeah, I've been doing it full-time for almost a year. But then, outside of it, I guess, for almost two years now. Yeah, Ruby was mostly my first language. I've delved into some others, like JavaScript, of course, and Lua, and a few others. But, yeah, Ruby was...it's just easy to ramp up pretty quickly and cling on to, I think. It's easy to read, you know, which really helps in learning the language if you can understand it quickly, and you don't have to think about it too hard.

MIKE: You say Ruby is easy to read. I think it's shockingly easy to read if you've been maybe working with another language for a while [chuckles]. Ruby lends itself to very friendly, almost human language-looking code, not in, like, a forced way. But it just...the idioms naturally flow such that it reads similar to human languages. And that means that your code ends up looking almost like documentation. And I think that has tremendous value.

MATT: It's the old joke that good code documents itself, right?

MIKE: Right. [laughs] And you say it's a joke, and it is a joke. Like, I don't need any comments. I don't need documentation. My code is great. Those are separate concerns. But the truth is, if you have code that is really easy to read, that has a huge influence on the ability of new developers to get up to speed. If you have very obscure code, you may end up having developers scrap it and start over again, even if the code was perfectly good, just because they can't understand it.

And if you can't understand something, you can't adequately maintain it, or you're taking so much time understanding it that you might as well have rewritten it, to begin with, and no amount of documentation can really fix that. So using a language and even just paradigms—this applies beyond Ruby—writing in a style that lends itself to ease of reading is a big deal, in my opinion.

MATT: I 100% agree with that statement.

EDDY: The toughest part about being a new developer or your aspirations is, like, shifting your brain to think in a certain way. And if you pick up a language that has a daunting syntax, it's just really hard to wrap your head around everything else. So, if you pick up Ruby as an introduction to the language or to programming, I feel like it starts cultivating your brain in such a way that it gets easier to pivot to other languages once you get your thought process and your brain thinking that way, or at least it was for me anyways.

MIKE: I've actually read, not for programming languages but for natural languages, that there's been some research that says that learning a language that's easy for you it sometimes...and there's even, like, artificial language like Esperanto, which is sort of this made up language that's the generalized European language that's meant to be easy to pick up, easy to speak, and follow some loosely Latin roots to make it familiar to people with some European background.

People who learn that language can then much more easily pick up their next natural language. So, if you are somebody who comes from a European language background, or Western language background, say English, and you want to learn something like Chinese, it can actually be faster to learn another European language like, say, Esperanto or Spanish, or French, you name it, first, and then learn Chinese. And you will actually learn, you know, you can go study Mandarin.

You'll actually learn that second language faster than if you started with the second language to begin with. [laughs] That stepping stone actually does train your mind. And there's research behind it. You can look it up. I don't have the reference right in front of me, but I've absolutely seen that. I think that that's strongly backed up. That's a really interesting point.

EDDY: So, yes, so I would argue, yes, Ruby, for new developers. So for people who are aspiring but have no prior experience.

MIKE: And it's also interesting because Ruby will encourage you to kind of go functional light, [laughs] to start thinking about things in some at least moderately functional way, as well as learning object-oriented, kind of an object-oriented paradigm at the same time. So if you're going to move on and go into functional languages, or if you're going to go on and do object-oriented programming, you've already had a taste of it and will be well prepared and have your mind thinking about how to think about problems in that way. I don't know that I thought about that as an advantage of Ruby before. I'm glad you brought that up, Eddy.

So we've talked a lot about kind of the utility of Ruby and where it's been good for us. Where are some places that you might not want to use Ruby? If you're going to take on a project, where would you say, no, I'm not going to use Ruby?

MATT: Personally, anything with machine learning, I would definitely go with Python, anything with a heavy CPU and, you know, file processing, things like that. And, historically, you know, I came from the healthcare world, and we used to have to process these enormous EDI files. And I did a test because, initially, we wrote these converters in Ruby. One of the files may take an hour to process in Ruby. I converted one of them to Python, and it took, I think, three minutes. So definitely anything that has to do a lot of heavy lifting and file parsing I would not use Ruby for.

MIKE: That's interesting. Were you using raw Ruby, or were you using some libraries? In particular, were you touching ActiveRecord at all?

MATT: No ActiveRecord. We did use some libraries that were a clone of some C libraries, but it just couldn't do the lifting like Python could. And, I mean, ultimately, C is probably the best answer. But there were very few people in the company who knew C. So we ended up converting to Python because some of us knew Python.

MIKE: Well, the interesting thing is that Python has a reputation as a slow language. And in some cases, Ruby is faster than Python. But, and here's the big caveat there, is there are libraries written in Ruby and in Python that are written in C. And so if you can exploit one of those libraries, you're just using a thin front end and a convenient language to use that really fast one. And it sounds to me like you were probably using some C code under the hood that was given to you by Python and --

MATT: Yes, yes.

MIKE: So you really were using C, right? [laughs]

MATT: Yeah, but we just didn't have to write it in C.

MIKE: Yeah, exactly. [laughs] I used a library quite a few years ago, in Ruby, that was a clone of the searching library from Java, Lucene, that underlies, like, whatever everybody uses for search. I say everybody, but that's not quite true, but it's largely true. Lucene is used by Elasticsearch and Solr. And pretty much every search solution I've seen uses Lucene under the hood. Somebody cloned it in C and made it into a plugin that you could use in Ruby.

And I used that in a tool that was called Ferret, I think. I used it a number of years ago. And it was so fast. It was so blindingly fast. It was wonderful and buggy. [laughs] And when we got some scale, it would just crash. So we had multiple parallel instances of it running, and the company I was working for was using it heavily. And we were growing really fast.

And over the course of a couple of months, it went from failing, like, once a day to failing, like, once a minute, [laughs] and that was clearly unacceptable. So there are some downsides to having that C behind the scenes if you don't have very well-written C that is heavily exercised by a lot of people and well-tested.

EDDY: So I read a while back, and I don't know how true this is because I haven't had time to back-check. But, at one point, I believe Ruby on Rails was accused of being difficult to upscale. And I think that's part of the reason why Twitter moved away from that to Scala, I believe. And I think that's what the initial conversation that sparked the debate around Ruby on Rails scalability issues. So I'm just curious if anyone has any experience.

MIKE: I have been in multiple startups that have grown tremendously, you know, that same company I was telling about that grew. We were serving about half a billion requests per month for a while. There's certainly bigger, but we had a lot of traffic. I read some articles about this. But I don't think that that was really what Twitter's problem was.

The problem was that they were using MySQL as a router, [laughs] and that aspect of the architecture was the key problem. And the language was largely irrelevant. And it was some fundamental architectural shifts, I think, that made the difference for them. I don't think that Scala is a bad choice. And I think that it probably made them somewhat faster in some regard. But I don't think that that was fundamental to their scalability issues. I think that it was something more fundamental architecturally.

Because, in modern web development, the way that you scale is you go out horizontally. And if you're using a somewhat slower tool, you can usually just scale out a little bit more and balance development costs versus server costs. And, oftentimes, the development costs are higher. So if you can make the development costs lower, you scale better, which is why people don't write all of their web code in C even though, technically, they could make it faster.

You know, most of it's done in interpreted languages [laughs] because the developer cost is higher, and it works. It works just fine. They can scale out. I really think that that is a false argument, from my perspective, because it suggests that it's crashing to use an interpreted language. And if that was so, then why is 65% of the web development being done in JavaScript? It doesn't seem like it holds water to me. That's my opinion.

MATT: I think you hit the nail on the head.

MIKE: To take that a little bit further, if the top languages are JavaScript, and Python, and PHP, [laughs] and that's what the modern web runs on, yeah, it blows that argument completely out of the water. Because, you know, Rails is a similar language, you know, it's an interpreted language. And they're all going to be, you know, approximately similar in performance. And you might get one that's twice as fast, maybe. But, in the end, that's just not going to make that much difference.

Again, the development costs are going to dominate over your server costs unless you're, you know, Facebook or Google, in which case, yeah, you should be using some really powerful low-level tools. And that's really not...well, maybe that's another place you wouldn't want to start with, Ruby. But the truth is, yes, you would because if you're going to be starting your startup, you're not Google. You're not Twitter. You're not a huge company X. You're some much smaller company.

And you want to be able to prototype and get to market quickly and be able to keep your development costs low. So you're not going to want to build all of the heavy web infrastructure to launch your tiny little site that supports one client to begin with. That would be a foolhardy way to approach your company.

MATT: I think that's a great point because when you are prototyping and trying to get to market quickly, you add a lot of tech debt, generally, right? Most initial applications are full of tech debt. And I think one of the nice things about Ruby and Rails is that refactors can go a lot more quickly than other languages. Extractions are pretty straightforward, for the most part. I think you're creating something that's going to be easier to manage and maintain until the necessity for something more powerful arises.

MIKE: Yeah. I think that's really well said. You're not going to scale to the size of the internet giants on your first platform. To your point about tech debt, what you build your first platform to do is not what your final platform is going to need to do. It's going to evolve over time. And I think you need to go in recognizing that that's the case. And maybe you'll be able to scale enough. And a tool like Rails or some of the other tools we've mentioned will scale enough.

Facebook has managed to do with PHP, and it's pretty much worked for them. Certainly, it's not going to be PHP all the way down, but you can make those work for quite a long ways. And then, for the time when you get big enough, we'll then use the right tool for the job.

KYLE: From a performance perspective, having supported different languages, different applications written in different languages in a production environment, moreso thinking about in a Kubernetes environment, because that's what we use here, I would say that there was a bias, at least in my mind, around some of these languages, Ruby included, where it was one of those one to two ratios, meaning one CPU to two gigs of RAM to run any of these things in a stable manner.

I wouldn't necessarily say that Ruby is the most lightweight. However, in the options that we've used here at this company, it does perform quite well. And scaling a Ruby application out with Kubernetes, meaning scaling it out with multiple pods, has been quite successful for us. So, like Mike was saying, maybe in a larger corporation where there is massive amount of traffic, Ruby wouldn't be the solution. However, from what I've seen with the traffic that we get, the Ruby apps do scale quite well, in my opinion.

MIKE: Spoken from a DevOps engineer there. [laughs] That's really interesting. Thanks, Kyle.

EDDY: Assuming that you do, in fact, decide, hey, I do want to build my website in the Ruby language, I was just curious to get the perspective of the group here on, like, why Rails is the top dollar when it comes to the framework. Because I know there's alternatives like Hanami, and Django, and stuff. But, like, what has set apart Rails that makes it that more important to use Ruby?

MIKE: There's always some advantage in numbers. So if you go with the more popular one, you're going to get all of the libraries available to use. You search on Stack Overflow, you're going to get your answers more easily than if you go out in another direction. On the flip side, if you have some strong architectural opinion, if you really disagree with some things that Rails is doing, then there are some alternative platforms out there.

And, a lot of times, you can even use some of the Rails stack. You can use ActiveRecord today, which is a powerful part of Rails, maybe the reason that they got adopted. And then you can still use that useful tool and put another stack on top of it. It may be more power to you, you know if that's something you really care about. It's going to be harder to find developers. It's going to be harder to find answers. You're kind of venturing off on your own. You're going off-road there, right? [laughs] But if that's something that you're comfortable with, then you can kind of become the vanguard, maybe even develop a following. It's a little riskier way to go.

I might also say that Rails has some opinions that differ from the majority, particularly some of the decisions they've made recently around JavaScript. If you disagree with those opinions, then you might want to use something else so you have a tool that better aligns with the way you see the world.

MATT: I think that's a fair statement. We need to use the right tools for the job, and there are, I mean, there are so many options out there.

MIKE: There are. Rails still is the heavyweight in the Ruby community. If you want to stay in a language that's similar, you can always go with one of the Python frameworks. And they range from heavier like Django to some lighter-weight frameworks, Flask. Ruby has the same things as well. There's a popular lightweight framework called Sinatra, as well as some others.

And I've written a Sinatra app before. And it was extremely successful. It was also an extremely small application, something that would work out well, probably in a lot of frameworks, something that might actually be a good fit for the JavaScript server-side, if that's the way you'd want to go.

MATT: Yeah. And there's been...Padrino is another option. And I think we've been talking a lot about Python. But things like Elixir, I think, are an easy transition as well if you want to go the functional route.

MIKE: Right. A lot of people get sold on the functional route. [laughs]

MATT: It's true.

MIKE: So, we've talked a bit about some good things about Ruby, some of the history, some reasons you might want to use it, as well as some places you might not want to use it. You might not want to use it [laughs] for doing any real heavy lifting on, you know, with file system or heavy CPU. You might not want to use it if that's not what the other people in your company are using.

But if you want to get up a quick prototype, I think it's really hard to beat Ruby as a language and Rails as a stack or one of its competitors because it's just so easy to get started. And I'm happy to still be using it, although I do use other tools as well.

KYLE: One thing that I got thinking about was the community around Ruby, or maybe just the atmosphere. And I'm speaking to this from having worked with different languages different developers as well. And both points of view, I have to say that I don't know if it's just a mentality in the community or what it happens to be. But some of the more friendly, easy-going folks that I've ever worked with have been Ruby devs, as well having to dabble in and troubleshoot Ruby issues.

The extended community, be it on Stack Overflow or other forums and stuff like that...not that other languages don't have this too, but whenever there's assistance needed in the Ruby community, it seems to be very respectful and very helpful, which I don't always see in other languages.

MATT: That's a really great point. I didn't even think about that, but I agree. The culture is a bit different for Ruby shops than, you know, some of the others, say, here's the extreme, say, like, a .NET shop, right? It just feels like Ruby shops have a tendency to keep that startup mentality, even as they scale. And Acima is a great example of that. We have such a great culture at this company, and you just don't find that so much in some of the more structured Microsoft-type companies. So that was a very, very good point.

MIKE: There's an acronym that's used in the Ruby community we were talking about a little bit before we started our recording (MINASWAN); Matz is nice, so we are nice. Matz is the creator of Ruby. I don't know if it's a mantra, but it certainly is saying in a community that we should be nice like Ruby's creator. And I've definitely found that to be a case, in general, and found a very welcoming, caring community among Rubyists, which is great. And that's maybe a great place to close our session. Hopefully, this is useful to you if you're considering [laughs] whether to use Ruby for your next project.

Thank you everybody who's been participating today: Matt, Eddy, Kyle, and Ramses. And thank you for listening to our session of the Acima Development Podcast. I'll catch you next time.

Today we talking about what inspired us to get into software development and become developers.

Transcript:

MIKE: Welcome to another episode of the Acima Development Podcast. I'm Mike. I will be hosting today. We've got a panel here today of Afton, Diane, Eddy, Ramses, and Tad with me. And today, we're going to be talking about what inspired us to get into software development, what inspired us to become a developer. I have the luxury as the host [laughs] of being able to share my story first.

I've been thinking about, as we've been preparing for this, what I might share, and I'm going to start back in childhood. And I may have shared this before, but I will share it again. When I was in elementary school, I don't remember quite what grade it was, like, second or third grade; our school got a computer. And this was a long time ago [laughs], back where the school would have a computer. And that was a big deal. We didn't have one at home. I'd seen computers at places of work but had not had a chance to play with one.

And our school got a computer, and I got to use Logo, which is a language, if anybody has used, that lets you move a little turtle around the screen and draw lines behind it. And I thought it was just the coolest thing to be able to talk to this computer and have it do something. And what I particularly remember is that there was some sort of key sequence or something you could do to go to a back channel where it wouldn't show you the turtle, but you could write a little script. And then you could execute the script, and you could watch the turtle do a few things. I remember you could make spirals, and I thought that was the coolest thing ever.

And you'd have the turtle go forward and then turn and then go forward again if you did it with the right angles. You could do it in a loop. There was some sort of looping construct. I don't remember what the looping constructs were. But I just thought it was like the coolest thing, and I wished I could do it all the time.

There was another kid at the school who was really good at doing this. I remember he used BASIC. And he inspired me. That's kind of a tragic story because he went on to be criminally prosecuted for a murder related to a drug transaction. But maybe that kind of pushed me away from it for a while. But there were other people around me who got computers, and kind of inspired me as well.

Later when I was a few years older in junior high, my family got a computer which was, wow, it's a big deal. [laughs] And it was, I think, an i386. It came with a book for GW-BASIC, so it comes with BASIC, which is a simple programming language. And there was a manual along with guides on how to do a bunch of things. And I read through the manual cover to cover and did some of these example programs, and I had a great time. I would spend hours working on that.

I had this from my childhood, and then I didn't really work on it for a few years. Again, as I mentioned, [laughs] my friend who had some interest in it went down a dark path. I kind of got away from it. And then, when I was in college, I was originally pursuing botany and genetics, molecular biology, and I got kind of scared off by that field because I didn't feel very comfortable with the lack of ethical constraints, what was going on. I'm kind of glad I got out of that industry because there are some ethical conundrums there that are challenging, but they are in every field, so I don't think it's escapable.

But then, in college, I was looking for what I wanted to do instead, and I took a coding class kind of on a whim. And I was like, oh, that's right, I loved this. [laughs] And I thought I could make a career out of this, and this would be a great career. And I never really looked back. I've been doing it ever since. And I've been coding full-time for over 20 years now. I've really enjoyed it.

There is a joy and a thrill in being able to solve problems and get this computer to do something productive and useful that is hard to explain to people who haven't done it. If you haven't done it, I recommend you try. Have that experience for yourself. That's kind of my background, what inspired me to become a developer. I could talk about more, but that's kind of the big picture of my progress. What are your stories?

TAD: I started out back in the early '80s. Texas Instruments decided that they wanted to get into this new home PC thing. And they came out with a computer called the TI-99/4A, and my parents got one for our family for Christmas. And it was just fascinating to me. There were these clunky things where everything was kind of contained in this keyboard that you plugged into your TV and that you use as your monitor. And then you got games or other things that came on cartridges that you'd slide in the slot in the front. And it booted up, and you'd play the games and do whatever.

But when you first started it up, it gave you an option screen; number one was basically programming BASIC, and number two was the option to boot up whatever cartridge you had put in. And for a while, I just kind of ignored option one. But then I was kind of like, well, what is this thing, you know, programming BASIC? [laughs] So I started choosing option one, and I'm like, oh, I could do line numbers in a loop because it came with a little manual you could read and figure it out.

And so I started out with the really simple stuff like the guess the number games or doing a loop like you are awesome and just prints it over and over again, whatever. And I did that for a while. Probably the height was I came up with a song, and I programmed the computer to play the song in a very electronic way. And I recorded it, and I submitted that for the Reflections contest. And everyone thought that was so novel. I made it up to region or something. And I'm like, yeah, computers and computer music and stuff.

But I think I kind of followed your path, Mike, where that was really cool when I was younger, and then I kind of fell away from it because there were other things to do. And I didn't get into computers again until probably high school because I had a lot of friends in the computer club. My computer science teacher in high school was kind of a visionary, I think, because she...this was back in '93, '92. And she was connected to this...the computers at the college were connected to this new thing called the World Wide Web.

This new thing like FTP [laughs] would be able to connect to that, and from there, we were connecting to the world, and this was back in '92. And we're like, whoa, what is this? And she was doing things like video conferencing. And it was like grainy, little black and white things. And we used HyperCard to control the LaserDisc player that she had. And it was pretty crazy. And that, I think, really reignited my interest in computers and computer science. And I was the vice president of the computer science club and getting into that.

But my real passion in high school was chemistry. And I got like a five on the AP chemistry test. I was just doing awesome things with chemistry. I got a scholarship in chemistry and got into the University of Utah. And I was sure that that was my path; that was what I was going to do. But once I got into college, I realized I really enjoyed learning chemistry. And I really enjoyed the fun things like blowing things up or making soap or whatever little projects that you do. But I really didn't enjoy the long-term labs. I didn't enjoy the reports. I didn't enjoy sticking samples in machines and writing reports, that kind of thing.

But I had all this chemistry, and I'm like, well, I don't want to lose the credit for that. Maybe if I switch over to something kind of parallel, I'll find my passion; I'll find what I want to do. So I switched over to materials engineering and was doing that. I wasn't loving it, but they promised us the third quarter is when they get into the real stuff, like the real stuff that you're going to learn about and do in materials engineering.

So I stuck it out. I took the third-quarter class, and I hated it. I don't know, like, it was so boring to me because a lot of it was stick a sample in the machine, collect the data, write a 20-page report, literally 20 pages. And we were doing that every week. I'm like, ah, this isn't what I want to do. And I kind of got bummed out and decided to just drop out for a while because my reasoning was, why pay money to do something that I don't enjoy?

And so I took a bit of time off to just go home, get a job, figure it out. And it was interesting because I was out mowing my parents' front yard, and one of my old high school teachers came by, and she actually mentioned she's like, "Oh, I thought you were going to go into computer science. That was what you really seemed to be passionate about back when I was teaching that stuff." And I'm like, oh yeah, [laughs] I kind of was. And I had been doing a computer science minor the whole time.

And it just dawned on me; I'm like, those were the classes I really liked. Those are the things I really enjoyed doing. Why don't I just make up my mind on my major and go back to college? And being able to take your thoughts and make them into something and just be able to create anything you want, just the variety and the things you get to learn and the things you get to do with computers turned out to really appeal to me. And so that's how I kind of switched paths. I went back, got my CS degree, and I've been doing this for, gosh, somewhere about 16, 17 years, I think.

MIKE: Nice.

AFTON: I'm really eager to kind of talk about my story now because it's quite a different path. I grew up with zero interest in computer [laughs] programs and, in fact, being very intimidated when I had to interact with computers. Occasionally, I was shown how to play a game on there. And in school, I knew how to get to my Word documents to type my papers, but that was it. I did not do any more than was absolutely necessary involving computers. And I knew nothing about programming and just had very limited exposure to anything of that sort.

And my passions were nature and dancing, and I was highly involved in music and theater. And I ended up...in school, I started out as a math major because I really had always loved math, and then switched to music and got my degree in music. And my favorite part about my music experience was the music theory, which was very mathematical, very exacting. I loved learning about how notes related to each other and the different sounds you can make by tweaking. And if you followed certain patterns and certain rules, you could create something beautiful. I loved that exactness and learning those little tools and the rules for creating something.

After I graduated, I started a family and stayed at home raising and homeschooling my kids and almost never interacted with computers except online, whatever. But there came a time where I needed to start a career. And I was looking for a way to gain some independence and support myself and something that would give me some flexibility because I had young kids and wanted something that could work with my life in some way. I had some people really close to me who had gone through QA and were then web developers and software developers, and them knowing me, they were like, "You should try development, writing code. I think you would like it. I think it's up your alley."

And I really resisted that idea. I was just like, no way. Computers, programs, I mean, I know nothing about that world. And so for at least two years, I was just like, no, that's not my thing. And I thought about going back to school to become a dance teacher or maybe going back to school to pursue biology more, which had been my minor.

But when it came down to it, I was thinking about, well, if I go back to school and invest a ton of money and a ton of time, that's one path to finding a way into a career. Or is there something I could do from home while I'm homeschooling my kids that I have time and maybe not as much money resources to pour into? Is there something I could do that I can give it time and less money? [laughs]

And so finally, in 2015, when I was in my mid-30s, I decided to find a free coding course online and take my first coding course. It was on Codecademy, and I took HTML and CSS. And it was so much fun seeing how I could type something, and then it did something on this screen visually, and I could play with it. It blew my mind how much fun it was. [laughs]

Over a couple of years, I dabbled with some various basically free courses that I could find online. There were so many resources. It was really incredible what I was able to find and do. And also my local library...I went to the library, and I browsed the software books, and I found one on Ruby on Rails by Head First. And so I checked out that book, and I went through it like I was doing school like a textbook, and I built my first Ruby (It wasn't Ruby on Rails; it was just Ruby.) application.

So about two, two and a half years in, I put my children into public school so that I could spend full-time basically schooling myself and learning how to write code and solve problems. I just thought it was really intriguing and super fun to have a problem I had to solve and to just have to chase it down, and search, and Google, and read documentation, and try to figure out how to build an app. And I found the problem-solving and the investigation just really thrilling. And it was just like a treasure hunt every day with a new problem I had to solve. [laughs]

So I guess I just found a lot of joy and intrigue in the problem-solving and thought; I do love this, and I seem to have skills that help me be successful. I'm persistent, and I love the nitty-gritty details of everything and finding out what I do can impact various things, and just really enjoyed it. So I jumped into the world as a summer intern for my first job, and that's still what I'm doing.

So largely, my motivators were finding something I could do that could help me to gain some independence financially. It's something that can support life, a well-paying job, and something that was intriguing and interesting that I could love. It was a surprise to me. And I was encouraged to try out this world, but it surprised me. And it's been a fun journey. I'm still learning every day what skills I can bring and learning as I go.

MIKE: There was something I was noticing, Afton. You said that your background was a lot different. But you notice that nobody who's spoken thus far started their career saying, "Yes, I'm going to go and build software." [laughs]

AFTON: [laughs]

MIKE: None of us. We started in something else, and for whatever reason, that wasn't the end of our journey. And then we went to coding either for the first time or went back to it and, like, wait, this is great. That moment of discovery when you can work with the computer and it does things that you say sparked something. It's interesting to me how much commonality there is between all of our stories so far. The specific year we happened to start, I'm going to argue, is not that relevant, [laughs] rather that we weren't there, and then we got into it. That's cool.

EDDY: I'd be lying if I didn't admit that a huge contributing factor for choosing this was the salary ceiling is much higher than most after a few years. That was a huge factor. I remember I took a small typing class in junior high which, by the way, in hindsight, [laughs] has paid huge dividends with programming, like, holy cow. I can be much more efficient typing what I want and stuff. So I don't know if knowing how to type is essential or if people require that as a skill, but it was fantastic.

But that class that I took, the teacher implemented a small HTML course to kind of fill in time gaps throughout our typing sessions. And we were able to change the color of text on the screen from black to red. I still remember I was like, what the heck? I got filled with joy, and I was like, dang, I was able to tell the browser what to do with a few lines of code. I was like, this is insane. I remember feeling super joyful in that, and I was like, dang, this is really cool.

But it ultimately was a hobby for a while, and even after high school, I didn't have much direction for what I wanted my career to be. And then, it wasn't until the pandemic hit pretty hard in 2020 and I realized that I have a small family that relies on my income. And I was mortified that I was going to lose my job; fortunately, I didn't. But that was a huge epiphany for me that I needed a specific skill that will prove to be more flexible and provide better job security.

Then I remembered that I found coding pretty fun and entertaining. So I spent most of my time at my job at the time during lunch...I boot up my computer, and I just downloaded an IDE, and I just began self-learning with videos and stuff. And I delved into the React framework I remember. I looked up what are the most high-demand languages, and React was pretty popular. And I'm like, sure, I'll pick it up. There were even times where I was on the clock, and I whipped out my phone and I watched videos. And I hit a point where I dreaded the job that I had. And I really decided to take it seriously.

I remember I tried going back to college. But first of all, I'm not very academic, and I ended up dropping out after the first semester. But I remember I spoke with someone there, and they told me, "Yo, you don't need a college degree. Going the academic route isn't really for everyone. You don't necessarily need to." And I was like, wait, you can be a developer without a degree? That's insane. That made me wonder, like, what?

But I joined Reddit forums and a lot of blogs and watched a lot of videos. And a lot of people were like, "Oh yeah, you can totally penetrate the industry," so that's what I did. And after three months of really, really being heads down with learning and being motivated, I shot a Hail Mary, and I applied at Acima for the QA position. Matt Rampey was the team lead at the time, so if he happens to hear this, hello. And I guess he really liked the motivation and hunger to really penetrate the industry and really aspire to self-learn.

So now I've been employed for about a year and a half. And I've been striving to push myself to get out of my comfort zone and, pick up backlog tickets, reach out to developers. [laughs] I was like, hey, like, help me out. And I attribute a lot of my success thus far because I've paired with most of you with tickets, and I attribute a lot of my success to you guys because of all the patience that you've demonstrated up till now.

MIKE: That's great. [laughs] And we love having you working with us too. I'm going to point out to our listeners again the commonality here. [laughs] Notice that nobody really knew they were going to do this right at the beginning, and then they discovered it and noticed how much joy it brought them. Thanks, Eddy.

DIANE: I guess what sparked my interest and my curiosity was a class I took in high school, I believe. It was computer science one. And I took it because it was just a class to fill in. And the teacher introduced us to Scratch just to make your own little game on it, and we did that for the whole entire year. We just mainly focused on that. And if I'm being honest, at first, it didn't really catch my attention or anything like that. I wasn't very interested.

And so as the course went on, it was really fascinating and really cool to create your own games, seeing how all the motions and the integrations that they had within Scratch. You could just make the game on there. After taking that class, I believe it was my senior year; I totally forgot about it, scratched it out, literally. [chuckles] And I went to school for marketing initially. And I went for about three years, so I almost graduated, but then I realized it wasn't something I wanted to do.

So I took a long break and I started working at Acima as a processing agent. And after being in the processing department for a bit, I decided I wanted to go to a coding bootcamp. And from that, I got inspiration from someone who I look up to, and she's more of a big sister to me. So she went to a coding bootcamp, and seeing her go through that and excel in that coding bootcamp and excel in her career after really inspired me to go.

So I went through the coding bootcamp and actually reached out to Afton after I had finished the coding bootcamp. And we did some pairing after work hours, and it was really great. And I was able to learn a lot. And then she let me know that there was a QA position opening up, so I decided to take the chance and reached out to Ryan, who then interviewed me. And that's where I am now. I didn't think I was going to really excel in the career, but yeah, here we are.

MIKE: One thing I noticed is you mentioned there was somebody who was like a big sister to you who inspired you to go forward. Afton, you've mentioned that you had a couple of friends who said, "Hey, you should try this." Tad, you said you had a teacher, a former [laughs] teacher who remembered you and inspired you, and I probably have overlooked. There's a pattern here of people being inspired by somebody. Am I picking up on this accurately that there was a mentor who made a real difference to you?

DIANE: Yeah, she actually also worked here for a bit. So she actually got me the processing role and then pushed me to pair with Afton. [laughs] So yeah, she is the one who really pushed me to do the stuff that I am right now.

MIKE: Oh, that's great. I know I've worked with a number of people who are just starting their careers. I'm thinking of somebody...I don't want to name somebody who can't be here and speak for themselves, but there was somebody who was just working at a front desk. I say just working, but it was kind of a demanding position because she was the executive assistant and did all of the [laughs] coordination of the company, but she was not doing a technical role.

And she came and joined me and some other developers for a mentoring session during lunches, kind of like what Eddy was saying. She just came and joined us during lunches, and we took our time during lunch to start teaching her what we were doing and let her pair with us and review our code. And she ended up some years later working here at Acima and has gone on, and she's leading a department at another company. Seeing that is immensely gratifying as a mentor.

Actually, one of my really good friends in high school went into civil engineering. And he had kind of gotten stagnant in his career and asked if I would take a few days and teach him and some of his co-workers a class on coding and kind of get them started into it, not as much as a bootcamp. Imagine a really compressed bootcamp; learn how to code in a week kind of thing. It's not enough to completely launch your career but enough to spark their interest. And my friend is now working at a software company and has been for a number of years. That changed his career.

Just a couple of examples of the little things you can do, just taking some time during lunch or taking a week to teach a class ended up changing the trajectory of somebody else's career. So we're talking a lot now about our time as the mentees, the people who were inspired. But the work that we do, even if it's just a little bit to help somebody else in their career, can make a huge difference.

TAD: I think it's interesting. I had to write a paper in college, and so I chose to write about why and how people get into development and things like that, and often, it's two things, someone has to have access to a computer and be able to interact in some way that sparks their interest. And then they also need someone to mentor them, or push them, or notice them, and put them on the path. Those are two things that people usually point to as what set them on the path.

As you were talking, I was thinking I know this person who used to be an accountant, so they used Excel all the time. And they're like, "Oh, man, I wish I could make this easier on myself." And so they started learning formulas, and they started learning macros, and they started learning these things. And they're like, "Oh, man, [laughs] I like this better than accounting. How do I do this?" And happened to have lots of friends that were all devs, and they were like, "Oh, you probably would like this." And suddenly, they're a developer now.

MIKE: That's really cool.

RAMSES: Funny enough, Tad, that's not exactly how I started, but before being a full-time developer and before I was in technical support, I was in more of an auditing position where I used spreadsheets quite a bit. And filling out spreadsheets manually it's really, really tedious, or processing information on a spreadsheet can be really tedious. So I spent a lot of time researching and learning how to automate some of the really repetitive tasks that I was doing, and that kind of got me interested.

I've always been kind of around computers because I was first exposed to computers when I was in elementary school, probably. And I played a lot of games, video games growing up. So I was always solving puzzles or doing quests in games. It sparked my interest in problem-solving. But once I joined a technical support role, I think that kind of drove my interest into development quite a bit because in my technical support role here at Acima, I would often do QA tasks, or I was starting to do more development work because I was always just around code.

So it was a good opportunity for me to just learn what was happening. And I was really curious in obtaining that knowledge, and I still am today. I spend a lot of my time learning new things and trying to be more efficient, trying to just push myself. That's what inspires me today is just getting better.

MIKE: That's cool that you were in Excel also. I remember thinking it was cool to write formulas in a spreadsheet, [laughs] the spreadsheet software I was using. This was before there was...so this was...a little hard to think about this way, but there used to be command-line spreadsheets, terminal-type spreadsheets. It would fill your screen, but it was very different than the graphical environment we have today, but it worked just the same. [laughs] They'd have keyboard shortcuts that you'd tend to use more rather than using your mouse, but otherwise, the experience really hasn't changed that much. [laughs] And I loved that. I really liked writing the formulas.

I also remember doing some computer-aided drafting in AutoCAD, and there's some scripting you can do there as well that I didn't do a lot of, but I guess it was quite sophisticated. And it was also interesting and fun. I guess I didn't really perceive that as coding. I think a lot of people have that same experience.

We thought, oh yeah, coding, that's just kind of something you do for fun. It's kind of an enjoyable part of the job. This isn't something you can make a career of. It turns out, yes, it is, and it's in high demand. We need people [laughs] who can do that. Anybody else have those experiences doing bits of code in places that you wouldn't necessarily think of as coding at the time?

TAD: I think it's interesting. I believe this is true that pretty much all Adobe products now let you do script stuff with JavaScript. And I know some designers who started off just, oh, gosh, I need to automate these tasks. These things I'm doing in Photoshop or Illustrator, whatever, are really repetitive. [laughs] I wish I could automate this stuff, or I wish I could figure out a way to save this file in three different formats so I can give it to whoever and didn't have to do that manually.

And they don't necessarily become full-on developers, but they start writing their own scripts. And they start sharing their scripts or downloading scripts that other people have written and modifying them and stuff. And so it's interesting to me to see that even things that aren't full on I'm a developer, they are...like when I'm helping a designer debug his script, and he's like figuring things out, and like, "Oh, I got the variable wrong," and all the tweaking and stuff. I'm just like, oh my gosh, this is ubiquitous. This stuff is everywhere, and a lot of people are doing a bit of development as part of their jobs, even though they're not technically full-on developing.

AFTON: This kind of reminded me because I was thinking, I don't think I ever did anything like that. But then I remembered before I ever took my first coding class, I had a blog that I spent a lot of time on, and it was around having premature babies because two of my children were born prematurely. So I had started a blog that I spent a lot of time writing for, and I had some management UI that I could tweak things, and schedule, and make changes, and change colors or fonts. There was a little bit of customization I could do.

But my husband at the time was a web developer, and he would be like, "Oh, look, you can go to this place, and you can see the code that's producing [laughs] your page. And you can actually mess with it." And so there were a few things I wanted to change that he got in and changed. And I remember being really excited that that capability was right there. But it was like a foreign world, and I didn't know how to interact with it. But now that you're mentioning it, that did spark this intriguing like, oh, that's cool. So there was a little bit of that for me.

EDDY: I have a generic question for everyone here. Knowing what you know now, what personality traits should a person have in order for you to recommend them to programming? Like, oh, yeah, you're this kind of person. I think you'd be a really good fit for programming.

RAMSES: Curious, probably.

MIKE: I was thinking the exact same way, curiosity, and tenacity.

RAMSES: Yeah, that's a good one.

AFTON: I was going to say they like paying attention to details or organizing. [laughs] Those are skills I find helpful. And also don't easily get frustrated; someone who's willing to push through, even when something is difficult, willing to keep digging and persisting on a problem until they find a way to make things work.

MIKE: Absolutely. That's what I was trying to aim for with tenacity.

AFTON: Okay. [laughs]

MIKE: Maybe it didn't land. [laughs] I couldn't agree with you more. I've said to people before that software development is mostly about frustration management. And I'm really not trying to be snarky. I mean that fully because you're solving problems. And frustration, by definition, is getting blocked when you're trying to solve a problem or you're trying to do something. If you're trying to work through and solve some things, of course, you're going to run into roadblocks. If there weren't any roadblocks, the problem would already be solved, and you wouldn't be solving it in the first place.

So being willing to keep digging, even when it's frustrating, you know, manage the frustration and say, "Yep. I'm frustrated, and I'm going to keep looking because I'm frustrated," rather than being dissuaded, and that also connects to the curiosity that Ramses was saying. If you feed that curiosity, that gives you the emotional strength to keep digging, even though you're frustrated. Is that consistent with the experience of you all?

TAD: Yeah, I'd maybe even add creativity, maybe orthogonal thinking, meaning you have to generate like a whole bunch of different possible ways that you solve a problem. And then you try one, and you're like, oh man, that's not going to work. Okay, I've got to back up and take a different approach at this. Oh, that solution doesn't work either. And being able to think of a few different ways that you could solve the problem, which is really hard to get, and they don't really teach in school very well, I think.

It's funny to me that when I talk to people, they'll make excuses like, oh, I wasn't really that great at math in high school, or something like that. And the general perception of what you need to have to be a developer is different than what I think you actually need. I've heard a lot of excuses. [laughs] Like, wait, no, if you want to run an atom collider, then you probably do need to be really good at math. You have to have a really deep physics background. But if you want to tweak your blog, do you really need that math? Probably not, right? [laughs]

EDDY: I feel like there's a stigma from everyone from outside the scope where they're like, "Oh, every programmer and computer scientist needs to have huge mathematical comprehension." And like, [laughs] it could just be that I've only picked up semi-easy tickets, but to this day, I have yet to really hit a block because I'm not able to understand a math formula, and that's something. It could be different for senior developers.

MIKE: Has anybody here read a "Mathematician's Lament," also sometimes called "Lockhart's Lament?" It's written by a professional mathematician, and his lament is that mathematics teaching drives mathematics out of everybody. [laughs] And I laugh a little bit, but it's a tragic take on how that curiosity and creativity that you're talking about, Tad, ends up getting lost from rote teaching and learning to memorize the ways of doing things.

But what professional mathematicians do is nothing like memorizing formulas; rather, it is exactly what you described of coming up with a bunch of different possible ideas and creatively trying to find other ways to approach a problem and then trying out and see if they work, which is play. And play has evolutionary purpose. It's what we do to learn about the world, but it's fun. The fact that it's useful doesn't change the fact that it is fun, [laughs] and it is rewarding, that it is a joyful thing to do.

AFTON: Mike, you mentioned learning through playing, and that reminded me that Ramses had mentioned that he loves learning every day and continuing to learn. I was thinking of that as another big drive to go into this field was that it would require constant and continual learning forever, and the challenges would always be new. And there would be new tools you could learn about to implement. And so I imagine this would not be a job that I could get bored at but that it would be constantly challenging and rewarding and always push lifelong learning, which really, really, I loved that idea. That was something I wanted.

MIKE: Yeah, it's true, isn't it? Not only is it something that will happen, but it has to happen. You can't have a career [laughs] in this field without the daily learning.

TAD: And it's not learning, just development. I've worked in the oil and gas industry. I've written software for the veterinary industry. I've worked at a marketing agency. So I've also had to learn those domains. I know a lot about how veterinarians track their medications and treat their animals and things like that. And I know a lot about a bunch of regulations about the oil and gas industry now and how they figure out mapping stuff. And it's everything, like, software is everywhere. And so you're learning development, but you're learning a little bit of possibly anything else.

MIKE: Maybe to take that a little bit further, none of us started a career in software, but we ended up there. And there's, I'm sure, need in whatever industry you're in, if you're in retail, if you're in oil and gas [laughs] industry, if you're a barista. You shouldn't necessarily think that software is somewhere else. There's probably a surprising amount of need for software right where you're at. And you might be able to pivot more easily than you think if you're not a software developer yet. Take that as a challenge. We need more developers. You shouldn't feel daunted by the fact that you haven't gotten there yet.

EDDY: Mike, I just want to point out that when you and Afton mentioned managing anger or pushing past those blockers, you know, frustration, I've hit that point with RSpec. I just want to say that. [laughs] But I'm pushing still, but it's a beast in itself.

MIKE: Take some time to talk to me for a few minutes. I'll give you some ideas that I think will help. Probably a good thing for a future podcast. That's a tool worth talking about. This was great. I loved hearing everybody's stories. I hope that it's inspiring to our listeners. Thank you for listening, and we'll see you next time.

Here's part two of how to break down product work! In the last episode, we talked about how to break down product work, and talked about the 'why' and the 'when'. Today, we tackle the 'how'!

Transcript:

DAVID: Welcome back to the Acima Development Podcast. We are doing the part two of how to break down product work. Last episode, we were going to talk about how to break down product work, and we ended up talking about why and when, and didn't get into the how very much. I'm your host, David Brady. Today we're joined on the podcast by Kyle Archer, Ramses Bateman, and Eddy Lopez. And it's exciting to see you guys. Let's jump in. So how do you break down product work?

EDDY: You know, Dave, this has been lingering for me in my back pocket since last week. But I was getting over an illness, that I wasn't very productive in our conversation. As you may know, I'm an aspiring developer. Within the next few months or so, I'm hoping to actively be getting paid to develop and write code.

DAVID: Nice.

EDDY: One of the things though...and I see this often, specifically from a QA standpoint, where a company will ask you, they're like, "Hey, we need this huge and large and pretty feature. Oh, and you got X amount of time to get it done. You look at epic, you look at the subtasks, and it's like 30. [laughs] And now it can seem a bit daunting to look at all the subtasks that you need to tackle. What's your approach when you feel overwhelmed when you look at how big a project is sometimes?

DAVID: I do not want these podcasts to turn into me holding court with you guys because I'm honestly not that smart. Let me kick that over to Kyle and Ramses. How would you guys break that down? Somebody comes in and says, "Hey, we've got this big product, and you're in charge of it. You're the lead developer." Obviously, you've got to break it down somehow because you can't work on a 30-point story. How do you break that down into something smaller?

RAMSES: I think for me, it would kind of depend on what the epic is and then looking at the stories and seeing if we could subdivide the stories if it is appropriate to put them in thirds, halves, whatever it was. And kind of give some pushback and say, "This is great. This is a lot of work. We don't have enough manpower to get this done," and express what we could accomplish in that given timeframe.

DAVID: Yeah, I like that. In the last episode, [chuckles] I came up with a horrible metaphor. And it was because I was in the wrong aisle of the bakery. In my head, I was thinking it's like a loaf of bread. You've got to start at one end of the loaf and get to the other end of the loaf. And this was a terrible metaphor. And I apologize to everybody [laughs] who waited through that last line. Turn the loaf of bread sideways or on its end and imagine it's a layer cake. That's the metaphor that I should have gone for in the last episode.

For me, when I need to break product work down, especially if it's a big thing, you know, every business, not every business, but a lot of a lot of businesses, there's a central object that is like a document or a record of something. And it is the central artifact of business that your company works with, so with Acima, it's a lease. At CoverMyMeds, when I was working there, it was a prior authorization request, like somebody wanted to get a drug approved. These documents are at the center of everything.

New customers coming in they get attached to this document, or they're applying to get into one of these documents. And then they get approved, and they're now in this document. And then they're transacting the business of working through the contract of that document, and all the way until it's all paid off. And then it goes into history. And so there are all these events.

Let's say you're at a business, and you've got some central document like this. Let's say you're at a legal firm, and it's a contract. We have people coming in, and they want to get a contract. They need to create the contract, join, da da da. Okay, that's fine. And you got all these servers, and they're running software, and they're prosecuting the business. Prosecuting is a terrible pun. Sorry, it was not intentional, but I am proud of it. Transacting all the business of processing this contract, right?

Product comes to you and says, "Hey, we need a separate logging service. Anytime something happens to a contract, we need you to go to the master contract server and pull down the main copy, like, the original copy of the contract. We need you to amend the event, attach the event to it, and then store it back into the system. And we need you to do it in a separate service." And so you're going to talk to the contract server. You're going to get this thing. You're going to add these events to it, and then you're going to push these events back up into some other service to record them. This is pretty straightforward.

Anybody that's worked in kind of a service-oriented architecture has been given product work where it's, hey, talk to this server, and that server, and that server, and do something that those servers can't do on their own because they can't see each other. They don't know what the other server knows. So your little job here is to talk to all three to have the knowledge that comes from all three of those things and do something with it. This is pretty straightforward.

The metaphor of a layer cake for me comes about because instead of just looking at the top layer of the cake and saying I'm going to build the top layer of the cake, the very top layer of the cake, is we're going to build the thing that downloads the contract from the main contract server. And we're going to build that piece of software, and we're going to build it complete. We're going to get every single field. We're going to get every translation bit. We're going to decode the thing. It's encrypted, so we're going to put an encryption key. And all of this is put on there.

But you don't go to the second layer of the cake until the top layer is completely finished. And so you end up with building this thing that can handle everything about understanding this contract that you've downloaded and how to get it from this main server. But the things that you need underneath, just one layer down, don't exist yet. And so you don't have a cake. You don't have anything that you can serve on a plate and eat.

This is how we did software in the '90s. You hear people talking about waterfall where you design everything, then you write it, then you debug it. You don't write code while you're debugging that kind of thing. The layer cake idea is if you want to take a piece of cake and serve it, you want to serve up a slice of cake as quickly as possible. And that means you've got to write just enough of that top layer to connect to the next layer down, and you got to write just enough of that to connect.

So you might sit down and go, okay, I'm going to connect to the main contract server, and I'm going to download the contract. The contract is encrypted. I don't care. I just want bits off of that server. If I can prove that those bits did not come from my server and they came from that server, that's good enough. So we pull this thing down.

There's some piece of the contract that's going to be unencrypted, like the ID number or something like this. If I can get the ID off of this thing, great, I'm in business. We go down to the next layer. The next layer is something that's going to decode or actually just parse the stupid document. So we're not even going to worry about the encryption piece. We're just going to decode can we find the ID field in this document? And then we go down to the next layer, and the next layer, and the next layer.

And eventually, you've got this super, super thin, tiny little application. It's not even an MVP, minimum viable product. It's so much less than an MVP, but it goes full stack from the top to the end, from one end of the cake to the other, or from the top of the cake to the bottom. It connects to the main server. It downloads the contract. It parses out the ID field.

It figures out, oh, I want to attach an event to this. It gins up an event, which just has an ID and a created at, like, there's no event information. It's just the minimum. What's the smallest event that we can create? It's just got an ID and a timestamp. That's an event that exists but has no other useful data. And then, we upload that event to another server.

And for this minimal piece, we're just going to connect to the event server. We're not even going to shove up the event that we created. We're just going to shove up an event with an ID of 42 and a created timestamp of now, and that's it. That's your entire slice. And I've got a really, really dangerous question for you guys, which is, why is that insanely useful? Or, if you prefer, tell me what goes wrong in building that? What problems are you going to have to solve in order to get that entire piece of cake put together?

I worry that I've told the story carefully enough that you guys might feel like there's one right answer or one wrong answer, and there isn't. Have any of you guys done software where you take this vertical slice like this, and if so, was there something really surprising that wasn't in your master ticket, you know, the epic story that you have to break down that you found out by building this thing?

KYLE: I think what I've seen when I've kind of approached it like this is it can be both beneficial and, I guess...harmful is not the word. But I'm trying to think of the word I'm wanting here, but detrimental, there we go. In the sense that when I'm doing a vertical like that, I see stories that are both missing and are both unneeded as I'm going along that route. So I think that's kind of the danger of doing it that way for me.

DAVID: Talk to me more about this because I'm literally sitting here bouncing up and down on my chair, going it's not the defect. This is the feature of this approach. Talk to me about running into these missing and needed stories. What does that look like? How does that feel? And how do you deal with it?

KYLE: I'm trying to think of how to respond to that. It's just...because you're going along and you just realize that...I'm trying to think of an example right now. But it's not going to quite work the way that you're wanting to. Maybe there's a faster protocol that you can use, so that's adding something, right?

DAVID: Mm-hmm.

KYLE: Or maybe you're realizing that you can't transfer as big of a file as you wanted, you know, there's a technical hurdle.

DAVID: Bingo.

KYLE: There's a legal hurdle. There's a security hurdle, you know, different things can get in the way. But as you're going along, you're learning, and you're also realizing what would make the feature or the system better so you can see where adding a story would be beneficial.

DAVID: That is exactly, exactly it. When we look at these layers in our head, or we think about these layers, we often think about, okay, inside this layer, I got to do this, do that, do that. And then you go to the next layer, and you think about what's going to be in that. And you don't stop to think about, wait a minute, how is this layer going to talk to the next layer or the one above? What are the implications of this?

And when you take a slice vertically through the entire problem space, those things jump right out at you. Right off the tip of the bat, you find out that, oh, you can't connect to the main contract server without a username, password, and encryption key. You don't have one of those. You've got to go to IT and get an encryption key. Like, oh, we don't have a story for that. But we've got this other story buried way, way down off the side. That's the entire communication between the contract server, and your service, and the service, and the eventing service, all have to be secured with encryption. Okay, fine.

And we've got this big sub-epic kind of an epic of itself which is to dig into the encryption and figure out how we're going to encrypt all these packets back and forth. And as you're struggling with this, you go to lunch with somebody from IT. And you're telling them about the headache that you're having with this.

And the person from IT looks at you, kind of cocks their head a little bit, and goes, "Why are you doing that? You know that this server is on a backplane all by itself. It's inside a LAN. I mean, literally, there's a physical wire dedicated to the communication between this server and that server. And everything that goes on that wire is encrypted at the hardware level, like, we built it that way. We built it that way for you. Why aren't you using this?"

And you realize, oh, the application encryption it's done. This entire story is wasted heat for us trying to encrypt packets that are going on an encrypted transport protocol. I, four or five years ago, worked on...and don't quote me on this, guys, because I'm not a security guy. [chuckles] But we had a whole bunch of services that needed to talk to each other, and we needed encryption over them.

And then we stepped back and realized we're doing all of this over HTTPS. And we're like, wait a minute, does this secure everything that we need? And we went back and like, why do we want this encryption? And we're like, somebody eavesdropping here. Oh, yeah, that's hardened, that's encrypted. Anybody eavesdropping on that wire is going to get encrypted packets, to begin with. It doesn't mean you're safe. You never think that with encryption or security. But to whatever degree of safe enough, we were already done, and we were just wasting time.

The opposite end is you come across stories that don't exist that you need. You need the encryption key to talk to the server, or you need an account on that server to download the contract. Or you run into a fun thing where your service talks to the main contract server. How does it know which contract to update? Well, it goes to the database, and it looks for things that have changed; okay, that's fine.

But unbeknownst to us, the eventing server, every time it gets a new event, it updates the timestamp on the contract to say you've been updated. Now what's going to happen the first time you try to tag an update and attach it to a contract? I'm grinning my evil grin. What's going to go wrong here?

KYLE: You create an endless loop.

DAVID: Exactly. You come in in the morning, and the server room is 140 degrees. And all the servers are spun up CPU bound. And they're literally, oh, I got a new event; I better attach a new event. Oh, I got a new event; I better attach a new event. Oh, I got a new event; I better...right? And they're just going, and going, and going. You don't have a story for this. And you're like, oh, how did we write it? We haven't even written the software. How do we already have a bug? [laughs] This is a bug that is in code that doesn't even exist yet.

It's because you sketched out how the thing was going to come together. You overlooked the fact that when we push this event on, it's going to update the contract. So, oh, okay, it turns out that we misunderstood the problem, and we're going to have to address that somehow. And you find that out when you take that little vertical slice. You serve up the thinnest slice of cake that you can. It doesn't do anything useful except it connects all of the pieces together, and that's immensely, immensely useful.

KYLE: And based on your example, it sounds like we got a decent load test on the server to know whether or not it'll stay up.

DAVID: [laughs] Yep. Yeah, yeah. If you come in and the server room was ice cold because the hard drives all gave out six hours ago and they've all powered down, we've just discovered a hardware condition that we might want to deal with at some point, yeah.

KYLE: Yeah, not production ready at all.

DAVID: Mm-hmm. I worked at a shop years and years ago that Amazon was...they call it something else now. But at the time, they had a product called RightScale. And this is at the beginning when EC2 and cloud computing was brand new. And what RightScale was was this ability that if you gave them a manifest like a Docker container...this is before Docker existed. But you gave them some way to define a new server. At boot-up, it would connect to a load balancer. Okay, that's great.

Now when your web server gets overloaded or starts running at 80%, 90%, 95% CPU, Amazon takes the template for that web server, spins up a new one, boots it up, connects it into the web load balancer, and now you've got another web server. And if those servers go up to 80%, 90%, 95%, it would spin up another one, and another one, and another one. And it was fantastic.

And this is back in the beta of EC2 when you could only have 100 instances total. That's the dark ages. Now if you don't have 1,000 servers in the cloud, you're not a real company. But we set this all up. We went home. Literally, it was like a Wednesday, and we went home. And we came in on Thursday, and the CEO is pacing back and forth, and he's like, "All of the servers are spun up. What the hell is going on?"

We go upstairs and we log into the console. And sure enough, we're getting errors from EC2 saying all your servers are spun up. They're all at 95%. And we're like, oh crap, oh crap. What do we do? What do we do? So we start diving into them. And we log in, and they're getting traffic. They're getting real traffic. We're like, what the hell? We needed two web servers yesterday, and now we need 100. What's going on? I mean, they got to be talking to each other or sending a loop to each other like the contract thing. What is this? What is this?

It was one of those perfect timing moments because we're pacing back and forth, and the CIO shows up at like 8:30, walks in the front door, and he's like, "Hey, did you guys see the bid on Oprah?" The company had literally been on The Oprah Winfrey Show the night before. And our servers had been getting pounded all night with real traffic. And the CEO went, "Wait a minute, this is all making us money? Heck yeah." It was fantastic. So yeah, occasionally, you hook something up, and it works correctly. And that's even more terrifying [laughs] than having it go wildly wrong.

EDDY: I'm just curious, have you ever found yourself in a situation where you felt you needed to push back when the breakdown of the work that was given to you was unachievable for the deadline that they're giving you? Because that kind of goes back to the whole how do you manage the workload? And so, in the event that is unachievable in your career, have you ever pushed back and said, "No, this can't be done?"

DAVID: I'll tweak the question a little tiny bit. What happens when the workload is just shaped wrong, when it's too big for the calendar, or they pulled half your team off to go work on Project X, which is the secret initiative down on the other department, but your workload in your calendar hasn't shifted? How do you deal with that?

KYLE: So I've been at a few companies, and they've all practiced their own...I feel like Agile and Scrum are used as buzzwords, and they're all practiced a little bit differently, regardless of where you're at. But one thing that I've seen that's kind of been common is everybody sizes. Everybody sizes things based upon your team's efficiency. And some teams use points; some teams use shirts. I had a team that used is this a pebble, or is this a galaxy?

And it was one of those things where during planning or after investigation, it was one where we'd go back and say, "Hey, this is no longer a pebble after researching it. This is a moon. This is going to take us much longer. We're not a moon team, you know; we're a mountain team. We can't get a full moon done in one sprint." And you'd have to go back and give pushback on that. And I just think that that sizing situation gave them a better understanding.

Because the people asking for the work generally are product managers or whoever it might be. And they're like, "Oh, this is just an easy feature." "This is just putting a new button on the webpage," or "This won't be that bad." And they don't understand the scope of the work. So that's kind of what I'm saying there is like, once you're able to put it in terms they understand as well, it's a little bit easier to push back too.

DAVID: There's a great thing that you're touching on here, which is that your product owner is somebody who's looking at your backlog. And they know that you have a velocity of 27.4 fiddly bits or whatever the velocity points are. And if your backlog has 12,000 story points in it, you're not finishing that in the next two weeks or three months or whatever.

I have worked in environments years and years ago where nobody had any idea when things were going to be done. And the closer we got to a deadline, the more management would come browbeat the developers. And I kind of got in the habit of just shrugging and telling my manager, "This takes as long as it takes. I'm giving you my best possible work. But I am one person; I can't make time." And sometimes, that was a difficult conversation.

I've had people that are like, "Well, make it happen. I don't care what you have to do." And I'm like, invent time travel, I guess. If that's really your management style, then I suggest you go cut a purchase order for a time machine. I'm going to need some resource support on that. The move into agile...and I like what you said, Kyle, about Agile with a capital A and a TM at the end of it is a product that we sell to teams. And then there's this idea of lowercase agile, which is just like the concepts underneath it.

But I did a Scrum training years ago, and I'm not a super big fan of Scrum. But I did the product master or something rather exceptional or whatever. Scrum is [chuckles]...they've got a whole certificate tiering racket going on. The most useful thing I think I took away from the Scrum training was this exact question of when we groom the backlog, and we find out that we thought this was going to take six weeks, and we've groomed the backlog, and it looks like it's going to take 18 months, what do we do?

And the Scrum trainer grinned an evil little grin and said, "You don't do anything. It's not your job." Your job is, to be honest. And it's your product owner's job to figure out what to cut off, and where, and what is more important. What do you want to have first? And she said something that I have carried around with me ever since. She said, "The framework creates transparency, and transparency is a bear." I love that quote.

Because, yeah, you sit down, and you say, "There's the backlog." Somebody comes in and says, "We need this done in two weeks." You pull up the backlog, and you say, "There's the line. I can fit this much stuff in the next few weeks. What stuff do you want in that box?" "We'll take that piece out and put this piece in. And oh, this piece that I've been telling you for six months is absolutely necessary turns out it's just UI tweaking. What we actually need is the ability to bill a customer, and we don't have that yet." So the important stuff suddenly gets put into the box, which is really, really great.

So I don't want to sound like I'm smug or defiant with the product team. But I am saying that there's a boundary violation here. It's like business' job is to decide what's important and what is first. And technical people aren't allowed to make that decision. It's not our responsibility, but it's not any of our business to decide what is first. But conversely, the business folks don't have any business telling the technical people how hard it's going to be or how long it's going to take. I tell you how much it costs. You tell me if it's worth it to pay for that, to pay that cost and if it is, we work on that first.

KYLE: I was thinking, like, that's what a lot of this is when you're in planning is it's almost a haggling situation. You're sitting there trying to say, "Well, we could get this much of this feature done or this much of this epic done." And they're going, "Well, that's not enough." "Well, okay. How about this? Can we do this?" And you're kind of haggling back and forth. And while you're doing that, you're also pointing out, well, this is going to put us further into technical debt, and you're vouching for the technical debt that you want to get done.

And it's this weird situation where you get into engineering, and you don't realize that part of your job is going to be sitting there haggling with the business over what you think is important to keep the business running and what product or the business thinks is important to keep running. Because new features are fun and shiny, but you got to keep the core up. Otherwise, if the core fails, then the business fails.

DAVID: Everybody hates legacy code, not me. I love legacy code. And the reason I love legacy code is because that's the stuff that writes my paycheck. That's the stuff that's making the company the money that the company pays me with to work on the cool, new features. So I love legacy code.

KYLE: As long as it's not spaghetti.

DAVID: How do I put this? You can love someone and hate what they do. [laughs] So for me, sitting down with some code that was written...I've mentioned this on another podcast, but I literally had to maintain some code that was written to win a bet. Like, the architecture was a bet. He basically said, "I can do this with one line of code." His team partner was like, "No, you can't."

He then re-architected the way the modules talk to each other so that one module cascaded into the next one so that you could just bring them up in a chain. And then you could just do objects dot map, dot inject, dot, dot, dot, dot, you know, and it was a long one-liner, but it was a one-liner. [laughs] The guy who wrote this is legitimately one of the smartest people I've ever met. He and I have had multiple conversations where he's like, "No, that one line of code was also the right line of code. It was the right way to solve it."

And my repeated concern with that claim is that that one line of code is impossible to maintain. We cannot ever change that one line of code. We will rework the entire rest of the application to support that one line of code because it's just burned deeply, deeply, deeply into the architecture. Everything is in support of that one line. I'm okay with that.

When you build a house, you've got to pick which walls are load-bearing. And that one line of code is absolutely the king truss load-bearing wall of the application. Yeah, you can get a piece of code. Anybody that worked in Ruby 10 years ago knows what it's like to have to maintain a PHP app with spaghetti code and servers that crash and don't give you error messages because you've got error reporting turned off in PHP and all of that fun stuff while working on the shiny, new Rails app that's going to replace the PHP.

And you get around the water cooler, and you're just like, oh, I hate this code. I hate this code. I hate the old codebase. I can't wait to work on the new codebase. And I've been there. I've done that. And then, a couple of years later, we were standing around the water cooler, and we were working on the 2.0 version of the Rails app. And we were just lamenting how awful the 1.0 Rails app was. And I'm like, oh, I hate working on the old code. It's not going to be like...the new code is going to be so much better. And I'm like, wait a minute, didn't we just leave this party?

So yeah, legacy code, by definition, is insufficient to the new needs because people that wrote it weren't psychic. They don't write it for future us. Anyway, I can hate the way legacy code is written and still love the fact that...I guess what I'm saying is maybe I don't love legacy code so much as I love paychecks, like a lot. I really, really like that part. I don't think I would do this job if I wasn't getting paid. [laughs]

KYLE: To kind of tangent off of what you're hitting on there, I think that's something like you said, it's water cooler talk. It's the running joke; oh, I don't want to go work on legacy code, or legacy code is so terrible. Well, the reason is because of situations like that where it's like, you've got this one line that does so much or a block of code, we'll say, file of code, doesn't matter. It does so much. And it's either so old, or there's something about it that makes it difficult.

But you telling another engineer, "This is horrible. This is going to take me forever to do," that's one thing. But somehow translating that and explaining that to product or business-like, oh no, this is going to take two to three times longer because it's a change in the old codebase, that's something that's a little bit more difficult to explain to these individuals. Because it's the same thing to them, you know, depending on the individual, but it's the same thing to them. And how do you get them to understand that situation?

DAVID: Honestly, I've had this happen a lot where you have this exact problem where it's like, oh, we can do this in four hours in the new codebase. But this is going to take us three weeks in the old codebase. And like, oh gosh, what's going on? Well, there are two big things that are going on; one is the essential amount of complexity. You're backing on to 70,000 lines of code versus backing on to 1,500 lines of code.

The 2.0 app doesn't do as much. The stuff it does do, it does beautifully, and it does elegantly, but it does it uncomplicatedly, if that's a word. It doesn't have to negotiate with all these other things. And then the other thing is there's often process that throws in. It's like; I can sit down and cut a feature on the 2.0 Rails app. And I don't have to do SOX compliance. I don't have to run this past QA. I don't have to run this through three separate code reviewers because it's this greenfield project.

There's no money depending on this. There's no auditing legislation that's going to lock us down, and you wouldn't want that. If you're cutting a new greenfield app and you're cutting that first slice of cake, you don't have the ability to pull that document down at all. Auditing for SOX compliance is a bad idea. That's going to slow you down and give you nothing in exchange.

Things like SOX compliance or other types of compliance auditing are there to keep you from breaking something valuable that exists. And when you're doing a greenfield application, there's nothing valuable that exists. You're building [inaudible 29:06]. You're just spinning code out of whole cloth. And so we often have the ability just to move faster.

But I really think it comes down to just...it's not that legacy code is inherently terribly complex. It's just if you've got a seven-year-old app that you're building against, there are seven years of history. And it doesn't matter if that history is really, really good or really, really bad. I mean, it does, it does. I'd rather have seven years of good history code to work on than seven years of bad history. But seven years is still seven years. There's a lot of stuff to pick up and learn and hold in your head.

And it's really hard to go through that and groom it so that we have borders that when you pick up this piece of the legacy code, you don't have to think about this other piece because we've built a wall between these. There's an interface here, so now you don't have to think about this. Where previous to putting in that interface, if you picked up code on this side, you had to be thinking about code all the way around it.

In that little slice of cake, we update the contract, and that updates the contract, which causes it to show up in a loop. And now we've got a new problem. And you get these surprising things coming in out of the side. And when you've got legacy code, seven years of legacy, it's all blindsides. You can't look around without getting hit in the back of the head by a piece of unexpected code. When you're building against ten times the size of a codebase, there's 100 times the complexity.

And I guess this is the dangerous thing that I'm saying, the code that we're writing right now here today if we don't have a dramatically changed idea of how to write clean code, or maintainable code, or good code, or well-tested code if you don't have a really clear idea of that, then the only thing you know for certain is that you're writing more legacy code. Two years from now, you're going to be hating this code. And some of that is experience, and some of it is unavoidable, I think.

Because you today don't know what's coming down the pipe two years from now, and you shouldn't. The entire Agile principle of YAGNI "You aren't gonna need it." Leave things unsupported until you need them because two years from now, you're going to be going through the code, maintaining some module of code that doesn't get used, and nobody needs it. Nobody wants it, but it's in the codebase.

And you're renaming some variable, or you're changing some API, and this module uses that API. It's poorly tested, or it's not tested at all. And you get into it, and you find out that this is using the API wrong, but I have to update it to use the new API correctly, and that, yeah, it's terrible. I'll stop talking about YAGNI. YAGNI is bad. Don't do YAGNI.

EDDY: You know, David, you touched on something that I kind of want to elaborate on. And this might be a topic for another podcast. You were talking about legacy code, and it kind of sparked an interest on how do you get familiar with a company's thousands of lines of codebase without getting overwhelmed? Because that kind of touches on it also. Do you recommend to get familiar with the overall design and architecture first and then you get familiar with the specific details of the code as you progress, or? Because I feel like there are some elements to the way work is divided.

DAVID: We are getting close to the top of the hour, so I've got a short answer and a shorter answer. The shorter answer is we should do a whole podcast episode about working with legacy code. I think that would be fantastic. The short answer is two things, one; you should go get a copy of Michael Feathers' book "Working with Legacy Code." That book is like 10 or 15 years old. I haven't picked it up in about five years, but I picked it up five years ago, and none of it was out of date.

It's dramatically profound the kind of stuff that he tells you. He literally tells you how to work with code that you don't know anything about. And I've really learned how to keep my elbows in when I'm working on code, how to edit a piece of code without affecting the next file over or the next module over or altering the interfaces. And I got that from that book.

The other piece of advice is read, read, read. Go get a project, download it, and then read the architecture and go, oh, that's how you're doing that. And then put that project down, pick up another project, read it, and go, oh, wow, they're using recursion here instead of for loops. That's weird. And you go along for six months, and you start using recursion everywhere until your teammates have an intervention, and they pull you aside and say, "Dude, please just use a for loop here." And you realize, oh, there's a good place for a for loop, and there's a good place for recursion, and I'm using them everywhere.

And yeah, read as much code. Your ability to navigate an existing codebase is largely determined by how many different patterns you're familiar with. So go get a new piece of software, download it, read it, lather, rinse, repeat. And look me up in five years, and you'll be a whiz at it. You won't be a whiz at it in five months. You got to stack as many arrows in your quiver as you can.

All righty, we're at the top of the hour. Thank you, guys, for coming. I really appreciate it. Kyle, Ramses, Eddy, this was a lot of fun. Be good until next episode. We'll talk to you guys later.

Today we talk about how we break down work and what breaking work down means?

Transcript:

DAVID: Hello and welcome to the Acima Development Podcast. I'm your host, David Brady. And today we have an exciting panel. We have Eric Martinez, Ramses Bateman, Eddy Lopez, Mike Challis, and Jonathan Greiner. And we have one of our product managers sitting in the back. He says he doesn't want to join the call, but we might drag him into it. Because today we're going to talk about how we break down work. I'm kind of excited about this. I've got some ideas that I want to throw out, but I want to hear what you guys have to say. Just a cold start, how do you break down work, or what does breaking work down mean?

MIKE: I can say that if you don't do it, then you break down. [laughter] You can break down the work, or it'll break down you. Several years ago, I worked on a project. We started as a group project. It was a special project day. We took a day...let's go work on something we want to work on. We extracted something. We made a lot of progress. And we wanted to keep on continuing with the project. I'm not going to go into details of the project; they're not important.

But somebody was left to continue the work, and this developer who was working on it had this huge project. And they said, "Okay, well, I've got this huge body of work to do. So I'm going to work on a little bit over here and a little bit over there. And I'm going to come back over here and do a little bit, and then maybe over in the middle somewhere." And they just kind of touched a little bit here and there as they felt like it.

And I watched that project, and two months later, very little progressed versus what it had been two months previous because all the complexity of trying to think about the entire project had to be held by the developer in their head. They're trying to think about the entire project. And so that lack of focus on individual pieces meant that it didn't ever get done. And this developer was capable and just hadn't taken the time to break down the work.

So we then took the project. We said, "Well, let's do this differently." And that actually was a turning point in my career where I noticed just how important it is to break down every project into manageable pieces. I kind of take my own blame here because this was a less experienced developer. I should have stepped in [laughs] and been like, "Let me help you." And yes, this is me not really realizing how much this was needed as well, and so it was a self-realization.

And I realized, you know what? Every time I've got a project, if I don't break it down into small pieces I can think about, then I'm not treating myself like I'm a human. I'm treating myself like I'm something else, and I will fail. I need to break it down into pieces that can fit in my head. Me and the team I've worked with have taken the time tried to encourage this that when we see a project, to break it down into those human-sized pieces.

And unless it's in a piece that you think that you can say, oh yeah, that's easy, you know, if I were to number this through 1 to 10...usually in development, we use a Fibonacci sequence so 1,2,3,5,8, 13. And the team, several teams that I've worked with have said, "You know what? If it's above a three, it's not broken down enough." It means we haven't thought through it enough to break it down into a piece that I can fit in my head.

And the teams that I've seen do this have been wildly enthusiastic about the results because you're looking at a mountain and saying, "Okay, here's your spoon. Go dig it." It's completely impossible. It's so daunting you don't know where to begin. But if somebody instead says, "Here's a molehill, and here's a shovel," you're like, okay, I can handle that. And there may be a million molehills, [laughs] but you can handle that. You can keep on shoveling those molehills all day, and it's very satisfying.

DAVID: As always, Mike, you've thrown about five things onto the table that are sparkly and shiny, and I want to chase after them. There's a topic that's near and dear to my heart called cognitive load. And that's just...I like fancy words because I'm that way. [laughs] But cognitive load is a fancy technical term. The load is how much weight is resting on your brain if your brain was a muscle.

And what breaking a project down does is it reduces the amount of cognitive load that any one piece takes up. And hopefully, you end up in a place where the cognitive load of each sub-task that you work on fits in your brain. You can pick up that task. You can hold the whole thing in your brain. You can lift it. You can carry it. You can get it done, and you can move on to the next one.

And when we make the mistake of going over cognitive load, we often don't know that we've done it. The fun thing about the human brain, like, a microscope cannot look at itself. And most of the brain's ways of detecting problems about itself don't work. Like, the brain can't think; I mean, you can think roughly about yourself, but you can't actively perceive your perception. You can't perceive what's going on inside your head.

So I have had to learn tricks to tell externally what symptoms are happening in my life right now that might indicate that I am overloaded at some level in a way that I can't feel. When your judgment is impaired, the first thing that gets impaired is your ability to determine if your judgment is impaired, which is how we get ourselves into trouble.

So side tangent to this, I'm curious if you guys have had that experience of knowing when you're overloaded. And how do you get around it? Do you just go, oh, this is too hard to think about? Or are there specific things that happen in your day-to-day job that tell you, oh, I need to break something down, or I need to do something different? How do you tell if you're overloaded or if your task is too big?

So, okay, so that's kind of a scary question. It's like, how do we know this? It's invisible. I'm going to leave that for us to think on. I have some ideas. The one that Mike...that you said was two months went by, and nothing happened on the project. I've been that guy, and I've done that amount of nothing. And it was a lot of work to achieve that much nothing at the end of two months.

MIKE: Absolutely. It's a ton of work to get there, yeah.

DAVID: So when I see a long period of time go by, and there's nothing to deliver to the client or to my employer, and it is coupled with me having very high amounts of stress, especially if I start feeling impostor syndrome where I'm like, I shouldn't even be programming a computer; I got no business doing this, these are all signals to me that I'm trying to run it way too high of a gear, that I need to gear down. I need to cut my tasks into smaller and smaller pieces. I need to get more leverage on this because I'm just not grinding enough hamburger to feed the family. I'm trying to do too much.

I'm going to be all over the floor with metaphors today. Good luck, guys. [laughs] But you're not getting enough done. And so when a long period of time with no progress and very high stress, but importantly, during that entire time, I have this belief that I should be making progress. If you drop me into a brand new project, greenfield go build this thing from scratch; I'm kind of okay if some lead time doesn't produce anything. I expect it, then. But if the project is underway and has momentum and we kind of know generally what happens next, and then I get nothing done for a day, or 3, or 20, that's one of my big tells.

MIKE: I think what you're saying is practically true.

DAVID: Oooh.

MIKE: Like, it's true at the large scale. You get two months in, like, wow, this project is going slow. My team has been working on this huge project or my team of teams. Our company has been working on this project for a year, and it's not making any progress. What have we done wrong? Or I have been working on this for three months, and I'm not making any progress. What have I done wrong? Or I've been working on this for two hours. What have I done wrong? And I'm not making any progress. What have I done wrong?

I think that the scale is somewhat insignificant, but you call that something vitally important. When you notice that you're not making progress, you're generally doing some sort of loop. You're wandering through the woods, and you're like, wait, haven't I been here before? Well, you probably have because people aren't very good at walking straight, [laughs] and so we tend to just walk in circles. Well, the same thing happens in your code, in your cognitive work, whatever it is, I think.

If you find yourself not making any progress, you're probably in a loop where you're just kind of banging away on something, stepping away, and you're banging away on the same thing and not making any progress. And that suggests that it's time to rethink your assumptions and your process.

DAVID: I like that you scaled that all the way down to some tiny thing that you thought was going to take five minutes. It's two hours later, and you've gotten nowhere with it. We talk about things that block tickets, like, when do we run into a blocker? And the original idea for stand-up meetings was this idea that you say what I did yesterday, what I'm working on today, and you raise visibility on anything that's blocking you from completing what you have to get done.

And the funny thing that I learned there is that the blocker is almost never something that you anticipated because if you anticipated it, then you say, "Well, what I'm working on today is this thing that has to be done before..." it's not a blocker. I know it's on my to-do list. And blockers, at least for me, they tend to blindside me. It's not like, oh, I need to write this database code, but I don't know the syntax for this new version of the database. It's never that.

It's, oh, I need to write this database code, but there's a person in the chain that I have to physically have a meeting with and talk to them face to face. And I have no idea who this person is. I don't know where they..., and so I spend like two hours trying to chase down this weird side task.

Or it could be in software, but it's, you know, oh, I have to track down this device driver for Linux so that I can even talk to the network towards the database because it's got some weird security protocol or something like that. And you end up just going down this rabbit hole chasing weird side things that you keep getting blindsided, and you keep getting rolled over by this and that for me is another big time.

So when I get blindsided, I often don't know I've been blindsided. I think, oh, I'm just chasing the next prerequisite to finish this ticket. And then yeah, two hours go by, and you're like, wait a minute, I bid zero points on this ticket. I thought it was going to be a five-minute chore with essentially no impact to the schedule. But here it is; I've burned most of my morning. What's going on? And like, oh, hey, everybody, did you know we need this TLS driver on Linux to talk to the database? Uh, no. Now you can raise some visibility and say, "This is what's going on."

MIKE: There's so much there that's valuable. I saw an article once that I think made a bit of a splash on Hacker News or something, but I'd have to go track down the reference. I don't have it in front of me. The article made this...I think it was just a blog post. But they made an assertion that the way that our work as developers...it probably applies to other cognitive work as well and probably even real physical world work. The way that the size of a project scales is nowhere near linear. And the trick is complexity.

If you look at something and there's a lot of complexity in there, there's a huge amount of unknowns. And then you get into all those tangles. You get in with one tangle after another. And a better measure than trying to say, "Oh, this is going to take five days..." we're actually really terrible at that because there's a difference between ways of calculating the midpoint. If you've got a set of numbers, you can say, well, the mathematical average or the arithmetic average, I should say.

So you add the arithmetic mean. You add them all up together, then divide by the number of things. You get some number in the middle. Well, that's one way of calculating which number is in the middle. And let's hold that for a second. That's one way of calculating the middle, and we call that the mean.

Another way is to line up all the things and pick the one in the middle. That's your median. And usually, if you have kind of a random data set, they're about the same thing. But if you have a highly non-linear scaling, you have one thing that takes 5 minutes, and another one takes 10, and another one takes three weeks; another one takes a year; maybe your median is 2 hours. And your mean is six months. And that wild disparity between your median and mean means that we're really bad at giving estimates because we tend to estimate the median and not the mean. And complexity can throw this huge, enormous wrench in the works that makes things take orders of magnitude longer.

So when you're estimating [laughs], you need to remember that you're almost certainly going to get wrong on the mean. You're probably going to be pretty good on the median. And one way to deal with that is to break the work down into smaller pieces so that on each one, you can kind of define the complexity and eliminate the possibility of some of those gotchas. It makes much better predictions.

DAVID: Wow, there are two big things that I love for that. The first one is that anytime you're trying to do a linear approximation of an exponential curve or a curve that just curves, something that doesn't go in a straight line, you end up with this dip below the center of the line and the ends usually shoot up past the ends of the line, and you end up way off everywhere, except for where the line accidentally crosses your curve.

The best illustration I've heard for this is that if you line up all the humans in the world and order them by the number of appendages that they have, the average human has about 1.99 arms, but the median human has exactly 2. In fact, you can go 80%-90% all the way up the curve, and 80-90% of the population have two arms. But there are people at the end of the curve that are throwing off the mean. If you drew it on a chart, you'd have this long flat bit and then a curve right at the end.

And if you try to draw a line from the top of that curve down to the bottom on the other side where everybody has exactly two, that line is never correct, except for the very, very beginning when you take that very first human, and you go, you have two arms, great. And you're the only one here, so the average is now two; great, carry on. And then, the longer you go, the more your estimate drifts.

MIKE: I found the original reference, by the way. His name is Erik Bernhardsson, and it's definitely worth looking up. If you look up his --

DAVID: Can you spell Bernhardsson? There's like three ways to spell half of the sub-words in the name.

MIKE: Yeah. Erik with a K, E-R-I-K, and it's Bernhardsson, B-E-R-N-H-A-R-D-S-S-O-N.

DAVID: S-S-O-N, okay.

MIKE: S-S-O-N. And I just googled software estimation median mean, and he comes up at the top because, like I said, it made a bit of a splash. Read that blog post, and I think you'll think about estimation differently forever afterwards in a better way because you'll recognize some of the gotchas.

DAVID: The other thing that you said that really hooked my brain there is this notion that as we get further and further away, something gets bigger and bigger. The difference between the curve and the line gets worse and worse and worse. I love the Fibonacci or even the exponential curve. I've gotten good mileage out of just doubling the estimates 1,2,4, 8, 16. And both of these, the Fibonacci curve and the exponent, we look at this as like, oh, the job gets bigger, much bigger, much faster the bigger it gets. And no, it doesn't.

It's just that our ability to be precise falls off exponentially. So if you've got something that's bigger than eight on a Fibonacci, that's what? Five, then 8, so 13 is the next one. On a Fibonacci sequence, if you've got something that's 8, you can't estimate a 9. You just can't. You try to estimate a ten you can't see your yardstick that you're holding up. It's really hard to tell if there are one or two full yardsticks. You're off by a full meter. So estimated down to the inch is an exercise and a folly.

MIKE: Absolutely. It's that, you know, the degrees of precision. The digits of precision are important. Maybe you can take the digits of pi out of 20 significant figures. But most of our measurements are nowhere near that precise. And suggesting that they're more significant figures than you are is actually going to give you bad information. It's suggesting a level of confidence that's wrong.

Usually, we're much closer to those polls that say, "Oh, plus or minus five percentage points." [laughs] It could be, you know, I'm going to give no decimal points at all, and I'm still probably off by 5%, you know, within about a 10% range. I felt like I did pretty good at that. That's far more likely, and honestly, our error bar is usually a lot bigger than that.

DAVID: Exactly. There's a fun thing that you run into if you're trying to put information out of the United States against scientific data coming from anywhere else in the world. And you will often find...especially if it's meant to be consumed by the average person rather than by scientists because if it's by scientists, it's all going to be a metric. And if it's going to be by the average person, you're going to see something like, oh, we heated this water to exactly 39.214 degrees centigrade. And you're like, wow, that's really precise. No, it's not really precise. That was just 99 degrees Fahrenheit. And don't quote me on that. I didn't actually check those numbers.

But you end up with, like, oh yeah, no, we were just rounding to 100 degrees Fahrenheit, plus or minus 10 degrees. But somebody just slavishly copied over 100 degrees Fahrenheit is exactly 38 point dot, dot, dot, and however many decimal places. And they copied up to five decimal places. And you're like, wow, that's super precise. No, no, it isn't. It's terrible.

MIKE: Which goes to this idea of breaking down work that you got to estimate loosely. I will make an observation here. A lot of times, we look at that and say, well, then estimation is stupid. [laughs] Why should I do any estimation at all? I've probably had times in my life when I thought that, but I've changed my perception on this because I do think that project estimation is useful, but not always for the reasons that you'd expect.

DAVID: There's an entire school of thought called no estimates, and it's a sub-genre or a sub-flavor of the agile movement. And there are some people that I really, really love and respect that really champion this idea, and I have not extracted that information from their brain. I just want to put a pin in that, Mike, because I think we ought to circle around to this in a future episode, maybe even trick one of those experts to come on and talk to us about no estimates, about why they think it's good and what problems that solves.

Sorry for interrupting you. I want to put that pin in there and then say what you and I have certainly found is that, no, estimates are good. They help us achieve what we...or we think they help us achieve what we want.

MIKE: Well, let me say that I think that they are terrible in general for telling whoever wants to know when it's going to be done that it's going to be done. But they're pretty good at telling us the scale of complexity of the work. If we look at it, and we can say it was, oh, that's pretty big. I'd say that's five. Well, then, we know that it's beyond what we understand at the moment. It doesn't fit in our head.

TYSON: And I think the other value of estimates is it helps planning. This is taking it to a more larger sense of a business scale. But if we can give the estimates, it lets us plan for the future of what's most valuable based on the estimate.

MIKE: Well, and what it does, it might not give you an exact date. But if we went to a project and we say, "That's kind of big," that gives you one thing, but if you go in and you say, "Well, I have these size two pieces, and there's 50 of them," well, that's far more precise. It doesn't give you a number of days, but it gives you a very good sense of the scale of the project. And actually, if you get in the habit of doing this as a team, of making these estimates, then you can actually sometimes map it to days not too badly if you've broken it down to that level.

It's a ton of work, and you don't do that until you're ready to work on it. But at that point, you can get actually...I've seen teams come within a couple of days, like two or three months out, when they estimated this way. It took over a week to come up with the estimation. So it's very expensive if you're going to plan out very far. You don't ever want to do this unless you're committed.

DAVID: I would also wager that the team that did those estimates has been working together for months and months or years.

MIKE: Years.

DAVID: And they can reliably...years, exactly. You can reliably say, "This is going to take Mike two days. And this is going to take Dave two weeks." You can literally go through things and say, "Yeah, we know as a team we have a collective sense for how long this is going to take."

TYSON: I think it's also important to remember these are estimates. And so you have to be pretty flexible to say, you know, if we're going to put a date on it, like, oh, it's going to be two weeks, but then also realize we gave an estimate. And if you go past that, okay, that's fine, and we can re-adjust and plan accordingly. There's so much value on an estimate, and you can use it as kind of a guiding light, but also, you can go off trail, and you're okay with it.

DAVID: There's a planning tool called Pivotal Tracker that some of our listeners are probably going to be familiar with. My favorite thing about Tracker is that it is continuously giving you an estimate. Basically, it says if you keep moving at the rate you're moving, then you're going to finish exactly on this day because you've put all the tickets into the system, which we can talk about why that's a bad idea. [laughs] But Pivotal always knows; Tracker always knows how long it's going to be until you finish. And it's important to not go...by the way, to the listeners, that's Tyson Novakovich. That's the product manager that I was hoping to get to talk on this call. So I'm very, very happy. Welcome, Tyson.

Tracker will tell you you're going to finish on March 23rd of, 2025. And you do not walk out of there going, oh yeah, we are totally going to finish this. Because every time you complete a job, Tracker goes, oh, you said that was going to take eight hours, and it took you seven. And your estimate moves from March 23rd of 2025 to February 15th of, 2025. And you're like, whoa, I just jumped the schedule by two weeks. And well, yeah, because when you estimate an eight, it takes you seven, and Tracker keeps track of that.

And it's always giving (I learned a term just yesterday.) a good faith estimate. And what this is is you're basically telling management, this is when I think I will be done, but please, please, please remember, every single day, I find out something new. I find out things that I thought were solved that we're going to have to figure out how to do. I found this piece. We've got this entire chunk of time dedicated to figuring out how we're going to talk to the Postgres database, but halfway through the project, somebody came in and said, "Oh no, we're going to throw it straight into the data lake. I want you to talk to Amazon Redshift instead."

And now this entire sub-module of put it into Postgres, which, by the way, everyone on the team is fluent in, now it's put it in this data lake. It's going to be way more powerful. There are all these problems that we were anticipating with Postgres that just go away because we're throwing this entire cluster of cloud databases at it. But also, nobody's familiar with it. And so we've removed this big known problem and, oh, look, our estimate goes way down. Look at that; we're going to finish in 2022. No. No, you're not because we just threw this big thing in there, this gigantic unknown.

So every single day, my point is, every single day, we're going to management and saying, "This is the good faith estimate. Don't buy ad space for the shipping date on that day unless you're willing to cut features. Because every time we take a step forward, we find new problems, and you guys add new features." Hey, wouldn't it be great if...Can we add this? Sure, sure, you can. Drop it into the system. And here's your new good-faith estimate.

And it's never a promise of when we're going to finish. It is a calculation of if everything stays the same; this is about when we'll finish. And unless you've been on a team like the one Mike was describing, where you've worked together for years, and you collectively know about how big the work that team can wrestle to the ground in how much time, you're going to be way, way, way, way, way off.

MIKE: We could easily dive deep into this estimation. I think we should probably save that for a different...We're talking about recognizing how to break down projects.

DAVID: Yes. But in theory, the topic for today is how to break stuff down, and we haven't gotten to the how. We're just talking about the why. And are you sure you need to? How do you know when you've missed it? [laughs]

MIKE: It is a huge deal because it is a part. Because if you start by developing this ability to estimate some...how big is this for me? Then you can get a sense of the scale of the problem. And I think that that's actually one of the first steps. Until you get a sense of the scale of the problem, it's really hard to break it down.

If you have something that really is going to take you five minutes, if you spend two weeks breaking that down into the sub-components, well, you've wasted some time. But if you have errors and you take five minutes on it, say, oh yeah, we'll get that done, well, then you have not spent nearly enough time. [laughs] So, some assessment of the scale of the problem, I think, is an excellent starting point.

DAVID: I like that. Very importantly, revisit that scale. So many projects I've worked on, I've said, "Oh, we're going to build this over six months. We've got these really big unknowns. But let's assume that these unknowns are going to shake out this way, this way, and that way." And then you go into Jira or whatever case management system you've got, and you enter in great big epics for all of those big things. And the problem is three of those epics end up never happening. And there are three hidden epics that never got put into the system.

And you will go four, five months in...I've seen teams slavishly build those three epics that we originally predicted on day one because we never circled back. We had this great, big meeting where we tried to break everything down in advance. And the problem is we broke things down. We were breaking things into ones and twos, but they were four months out where we had no business breaking anything smaller than an eight because we don't even know if we're going to do this. This might be a zero because it vanishes from the schedule entirely.

My point there, revisit the grand scale of the thing. Don't just have one big meeting. Having a big meeting is fine. That's what I'm saying. But have that meeting again. Don't think that meeting is done and done forever and that you're never going to circle back. You need to circle back and say, okay, our good faith estimate has changed by this much. Why? What's changing, and what do we need to put on here?

And you have another big meeting, and you go through everything that's left to do, and your good faith estimate changes. I'm not a huge proponent of big meetings. But sometimes, they are a bad, bad solution, but they are sometimes the best solution. You might not have a good solution to something, a big meeting for me is that.

MIKE: Okay. So you get the people together. You get an assessment of the size of it. And then what comes next? I read a book. This was in "Team Topologies." Well, I listened to it somewhat recently. And it talks about how teams ought to be structured, and they give this great idea. If you look at particularly sedimentary rock, it has these natural layers, these strata. And so there are natural fracture lines. This is true of other kinds of rock too. There are seams within the rock. And a skilled stonemason, and times have passed, but probably still today knows how to exploit those seams to split the rock in the way that they want.

They're not going to go and just start banging on the rock and hope that it breaks into half. Instead, they're going to study the rock. What are the seams here? Where are the natural lines that it would split? And let's look for one of those just splitting the rock because then it's going to split cleanly. Well, I think that we need to look for those natural fracture lines in the work. So we say, oh, we got this huge project. Well, what are some natural components here that we can start to break it down on? What do you think of that idea?

RAMSES: I think those are interesting points. I often think about how important it is to understand the requirements before even starting a project. And then, if you're working with a sub-team, we're finding those requirements so each member of the sub-team understands those requirements. And what often happens or has happened is requirements change mid-project. And as long as those new requirements are discussed, just having clear communication and refining those requirements, like, constantly refining those requirements, helps to move a project forward, I think. And it makes it easy to break down a project and think about a specific component of that requirement.

DAVID: I like that. Try not to lose track of what is it exactly that we're trying to build. Don't get so laser-focused on what you are building and say, oh, I'm building the database adapter. And then you peel off for six months trying to write a general-purpose universal database adapter when it turns out we just needed to be able to do two queries and an insert. We didn't need to do anything else.

MIKE: It's interesting that you focus so much on understanding and shared understanding as well. Developing that shared understanding you said was critical to breaking it down because if you haven't gotten some understanding first, it's not going to work so well.

RAMSES: Yeah, it's hard to solve a problem if you don't understand it, like, why it needs to be solved. Because the product or the business can say, "Oh, solve this," and if you don't know the intention or how the end user is going to be impacted...

MIKE: So every product manager out there listening or in the call, [laughs] if we don't understand the problem, we can't build it. So your work is invaluable, and it's about helping us understand the problem. You can bring the engineers a description of the problem. We don't really need to know how to solve the problem; that's what we do. But if you can bring us a description of what the problem is, a succinct and actionable description of a problem, here's the goal, here's the problem, here's what we want to solve, we'll know it's solved because of this, that is what engineers live on, a problem that's well-described that we can go start working on.

TYSON: I wanted to...I think one thing you said, Mike, about the stonemasons looking for the key part of the stone to aim for, is when I hear that, I think of, well, that's how we aim for MVPs. If we have a big massive problem or project that we're trying to do, what's the MVP or the minimum amount of work that we can do to get to solving the problem? And then, from there, breaking out smaller parts of the project to improve upon the MVP. But MVPs are super valuable, and it may not be the most polished thing ever, but we're going get something out that solves the problem that we're trying to solve for.

DAVID: I love that. I've got MVP in my notes here, the minimum viable product. And I was hoping somebody would bring this up because at the very top of the call, when we said how do we break down work, the two things that my brain immediately jumped to are, let's treat this like a rope and slice the rope into pieces just from one end...We'll treat it like a loaf of bread and slice each slice up from one end to the other, working your way from one side to the other.

Where MVP, the minimum viable product, you sit down, and you go, what is the first thing the system needs to do to be considered not complete and feature complete but like, what's the very first thing the system needs to do to tell us our idea could ever possibly work? So it's like, I don't need to insert and delete from a database. I just need to connect to the database. That's arguably not a viable product. It's certainly not for the 1.0 of the thing we're trying to build.

But the first time I do this, I need to connect, and the second time, I need to hand a query to the database where I can just gin up this entire long string and just shove it at the database. Eventually, I'm going to have to build this whole adapter layer that can take these objects and spread them out and turn them into that query.

But I like the MVP because you kind of like take one corner of the...like, if the project is this great, big rectangle, you take one corner of it, and you just slice a little circle, you know, slice one corner of it out and you say, "This is my product." And then you slice another piece and another piece, and you just keep sticking them onto the thing that you've built.

And from the get-go, you have something that doesn't do everything you need, but it does something. And you can test it, and you can verify to yourself from now until the project is finished; everything we've done up till now still works. I can still connect to the database when I put this piece. I really, really like that. It gives me a lot of safety and security to know that something I just built didn't ruin everything we've built up.

MIKE: Do you remember when the iPod came out?

DAVID: Mm-hmm.

MIKE: How well was it critically received?

DAVID: Oh, that part, I don't remember.

MIKE: It was widely --

DAVID: Actually, I do. Penny Arcade is a webcomic that I used to read. And the way that I loved it was you could buy...at that time; you could buy a Discman, which is a CD, portable CD player. You could buy one of these for $29. And the iPod was $300, if I recall correctly. And people were like, "Oh, but when you listen to music in digital format, it never skips." And the Penny Arcade strip that I remember, he says, "My Discman doesn't skip either because I padded it with $270 of cash to keep it from bouncing around. [laughter] I'm using dollar bills as packing material." Yeah, it was a terrible idea.

MIKE: Everybody thought, like, critics said, "It doesn't have nearly the features of its competitors. All it really has going for it is it looks nice, and it's got an easy-to-use interface. But who actually goes out and buys and listens to music?" Well, it's like teenage kids who don't want to go and figure out a complicated nerdy interface to listen to their music. If they can press some buttons and easily get to where they are and play it, that's all they care about.

And that product was probably embarrassing to a lot of engineers who built it because it did almost nothing. You'd put a few songs on it, and you'd press play. Well, they iterated on that. They came out with a consumer product. Apple was not when that thing came out, the behemoth they are today. They were trying to recover. And they came out with this consumer product that was kind of outside of the normal things they'd been doing. And they just sold these kinds of weird computers. And they came up with a smaller consumer product to test out the market. Well, it worked.

They put out this minimal product that was good enough for some people to buy it. They didn't put out a massive smartphone that had three cameras on the back. They put out a thing that would play some songs. And you could press kind of like play and pause, and that's about it. And then they made it a little bit better, and then made it a little bit better.

And a few years later, they said, you know what? What if we take the same idea and we apply it to phones? And they birthed a whole industry and have come to dominate it and become what? At least at this time, the most valuable company on earth. Because they started with that incredibly simple minimum viable product, I think that should be a strong lesson to all of us.

DAVID: There was a lovely sea change that happened in the world, not just in the industry but in the world where prior to the iPod coming out, we generally consumed our music in albums. You would go buy a cassette or a CD, and you would throw that chunk of physical media into your player. And those were the tracks that you had available. So you listened to the album in the way that the producer layered the tracks. Like, bands used to stack their songs in an order that we're going to come out of this song and into the next one. What DJs do now bands had to do with their own music and present it to you in that format.

But all of a sudden, people are now doing...they're arranging their music into a thing called a playlist. And I had never done that prior to this. I was a stick in the CD; oh, I'm going to do this work today. ELO "Time" is going to be a good album to listen to today. And all of a sudden, I'm sitting at my computer, and I'm dragging all the tracks out in order that are all 170 beats per minute because I've got to really knuckle down and work really hard, really fast, really intense, and I need some really fast music.

And all of a sudden, I'm throwing in classical music, and I'm throwing in heavy...it's like when you come out of Vivaldi's "Four Seasons" and run straight into Rob Zombie. It's a little bit of a whiplash. But it worked because they were the same BPM which no producer has ever put together. Well, I'm certain that's wrong because now people can go buy an album that's just running music, and you literally buy the album at the BPM that you want.

But the playlist, the idea of you're going to sit down and figure out what you want to listen to in advance. And now you strap the iPod on, and you just push the big red play button, and that's the only button you need. And that was a sea change. Prior to that, we needed the seven different controls because I love this album, but I can't stand this track. I've got to be able to skip over it whenever I want.

MIKE: A fundamental change in the industry was sparked by people just simplifying, by the engineers saying, "What's the bare minimum we can do?" And it forced a rethink of the interfaces and the way we even think about the problem. Well, we're talking about how to break down a problem, and if we don't start there, we're probably doing it wrong. We have to start, like, what is the bare minimum we can actually do? And it may force us to challenge our assumptions to say, "Well, what can we really get away with here? What can we really cut?" And maybe there's a lot more than we thought that we could.

And if you're not being uncomfortable with the cutting, then you're probably leaving the project too big. You need to truly make it minimal, or else there's some of that complexity that's going to kill you. That non-linear complexity is going to make it take way longer than you expected. You need to shave as much of that as you possibly can to get something really tiny because if you get that really tiny goal, it's achievable.

And once you have something that works, well, now you've got something where before you had nothing. So that jump from nothing to something is the hardest part. And then you repeat and say, "What's the next minimum thing I can add to this that actually provides value?" And you aim for that. And you just put it on repeat. [laughs] You put that, and you do that in a cycle.

DAVID: I worked with project managers 15-20 years ago who told me to my face, "There is no minimum viable product." I must have every single feature down to 100% completion, or the entire project is worthless. And I opened up the project, and there were like two weeks spent polishing the user interface. And I'm like, this is...no, we need to teach you what an MVP is at this point.

I love that you said if you're not feeling uncomfortable while cutting features, you're not cutting enough. You have to remember; you're not saying we're never going to build this; you're just saying I'm not going to build this now. We're not going to sell this to a customer without this piece. But can we stand it up and prove to ourselves that it works right now, is useful?

The phrase that I like that's related to the uncomfortable one. I think it actually used the word ruthless, which is kind of like the mental image of a programmer just head down, looking up at you through the eyebrows with an evil smile and basically saying...the phrase that I loved was every feature must fight for its life, or it does not get to live on the project schedule. That's what you should be asking when you're trying to figure out an MVP. Look at any feature and then say, "Can we just not? How much of this can we not do and still move forward?" I love that idea.

If you're taking the slice of bread analogy and you've got to move data from...okay, this is a terrible mixed metaphor. You got to move data from one end of the loaf to the other, [laughs], but you've got these layers. You've got to move...you got the user interface layer. You got the client layer. Then you got like the middleware, and then you got the back end, and the backplane, and the messaging system, and the data system. You got all these layers.

If you have somebody sit down and say, "We have to build this slice of the project. It has to be 100% complete before we can move on to the next slice," I promise you that person is wrong, and you are looking at the project the wrong way. That's the maximum viable product is to finish that layer 100%. What's so much better is to take one tiny little core sample of that slice of bread, and then build the core underneath in the slice below it, and then build the core of that under the next slice below that.

And eventually, you end up...it doesn't look like a loaf of bread. It looks like a string of beads from one end to the other. And you can't run any useful data through it, but you can run a ping and get a pong back. And that pong came from the database server, which was on the other side of the network, which was through the enterprise backplane, which was through the messaging system, which was through the back-end front-end middleware all the way up to the client. And that first time you get that pong actually coming out of the database server, it's very exciting as a programmer. I love that.

MIKE: It gives you the skeleton that you can start building on.

DAVID: Yes.

MIKE: When they build a house, they don't start with the siding. They build the frame. And that's not how houses have to be built. They can build the kitchen, and they could finish it and put all the flooring, you know, paint the walls, put in the cabinets. You get that done and then move on to the next room. But nobody does do that because it doesn't work out very well for a project.

If you can build out that skeleton, then there's stuff to hang everything, stuff to hang your sheetrock, stuff to hang everything else. You can start to work in parallel once you've got that frame. And you can see it and have an organizing idea. And getting up that skeleton is a huge turning point for the success of the project.

DAVID: Absolutely. You absolutely can paint the wall before you build the wall. I realized that sounds bizarre and weird. But you don't want to just sit down and stretch a tarp over the wall and then paint the tarp. That's not how you want to do that, but you can. There are people who do critical path analysis, and they figured out that you can build a complete house with foundation, and cement, and electrical, and finishing work in like 18 hours of continuous time. We started at this time, and 18 hours later, we were done.

But yeah, the walls were assembled on the ground, and the primer coat was put on the walls while they were still on the ground, and absolutely, you can do that. But it's a really weird way to work. And you have to know exactly every messy, little side tangent, and in software, we often don't have the luxury of that. So it's much, much better if we can just go; let's dig the foundation and find out are there any pipes that we have to work around? And, okay, let's pour the foundation and find out any problems we've got there. And it's much easier to paint the walls once they've been built.

I feel like we now need to do another episode on actually how to break stuff down, [laughs] like how to break something into an MVP and what constitutes an MVP. There are still some open questions here. But Ramses, or Eddy, or Tyson, is there any kind of a coda that you think that we either need to touch on or that you touched on really well?

TYSON: I think it's much of the how, but I think even with the project itself is the why of it. And so really covering all our bases on the why we want to break things down is equally as important as the how. It's a good overarching summary of what we talked about today.

DAVID: Awesome. Gentlemen, thank you. This has been the Acima Development podcast. And, Mike, we'll have to talk about maybe splitting this...maybe changing the title into why break things down and then maybe circle back. I think that would be a fun segue. Or maybe we'll just call this the how and let people extrapolate from what we've said. Thanks, everyone, for joining, and we'll see you next week or in a couple of weeks.

Today we dive in and talk about what we study to continue learning.

Transcript:

DAVID: Hello and welcome to the Acima Development Podcast. I'm your host today, David Brady. And today on the panel, we have Mike Challis, Eddy Lopez, Ramses Bateman, Kyle Archer, and Afton Call. Welcome, welcome, everybody. How's everybody doing? It's been a while since I've been on.

MIKE: It's good having you.

RAMSES: Yeah, it's been a while.

DAVID: It has. It's been. It's good to be back. All right, today we're going to dive in and talk about what do you study to continue learning? And I'm kind of excited to talk about this because this has been actually coming around on my feed and the things that I listen to. I've actually got some unusual answers to this, and I'm kind of curious. But I'm going to throw it out to the room because you guys know that when I show up, I talk too much, so somebody else talk. What do you guys study to continue learning?

MIKE: It's an interesting question because when I graduated from high school, my career didn't exist; that is, you couldn't be a web developer. That role didn't exist in the early '90s. There was no such thing, right?

DAVID: Yap.

MIKE: It didn't really exist in a meaningful way for some time after that. We've touched on this idea before on the podcast that there are some accidents of birth and your background that sometimes affect your career trajectory. This is kind of a big deal. The industry is changing, and it's a new industry for web development in particular but kind of anything that touches the internet that didn't exist in any meaningful form. So if you're not learning, [laughs] you might not even have the chance to have a career because, like I said, the career didn't exist. Mobile development didn't exist...what? Ten years ago, 15 years ago. That didn't exist as a profession because there was no such thing as a smartphone.

DAVID: I saw an actual study on that. I cannot remember the number now, but it was an alarmingly large number of people in the technical sector who had jobs that did not exist when they started college. They graduated and went straight into a job. And their job is ecclesiastical brand manager, or technology evangelist, or data personality manager. What is any of this stuff? And yeah, if you're not studying now to grow yourself, there are entire jobs coming that you're not prepared for because it's not coming down the mainstream curriculum.

MIKE: And that you couldn't be prepared for. Yeah, there's not going to be a university degree for it because they'd have to invent the field, right? [laughs]

DAVID: Mm-hmm. Yeah.

MIKE: And you're not going to learn mobile development in college if the iPhone hasn't come out yet. There's a chicken and egg sort of problem; one of them has to come first.

DAVID: And academia is 20 years behind, right?

MIKE: Yes.

DAVID: I remember in 2005 or 2006, the people that I was working with that were coming out of BYU were all Java programmers, and I was really surprised by that. I'm like, when I went there; it was C++ and assembly language. And, oh, you guys are now doing Java. Java had been out for ten years, '96, I think, '94 when it came out, and now it's in academia. But everybody that was good at Java had been programming in Java for 5,6,7,8 years. And it was just now showing up in the colleges.

MIKE: And I think there's always going to be that lag. I mean, just in the best of all possible worlds, you had some really forward-thinking professor who notices a new thing, takes the time to gather the information, stays up to date on the latest state in the field, and writes a textbook. That doesn't happen overnight. In the best of cases, you're probably going to be at least a couple of years behind the industry.

DAVID: Oh yeah. There's a weird sentiment that I've actually heard a professor express, which is that universities have an obligation to present grounded, well-spread fundamentals, which means they actually have a duty to avoid fads. So the only way to avoid a fad is to wait for something to stand the test of time, and unfortunately, that takes time.

MIKE: So back to your question, [laughs] you got to stay relevant. And I enjoy learning. I enjoyed school. Let me clarify that because there are a lot of people who are like, "Oh man, school was awful." There are some aspects of school that can be wonderful and others maybe not so much. You look at little children, and they love to play. They love to explore. I look at my young kids, and they like to try out new things all the time. It's innate. They find great joy in creativity and exploration.

And if that's how you define school, hey, school is great. I get to go learn new things and try new stuff. That's play. But if school is learning things by rote and getting in big trouble if you made a mistake somewhere, well, that's not fun at all. So I clarify a little bit [chuckles] that when done right, I think for people in general, we have that innate curiosity and deep longing to try new things and to explore ideas. So yeah, that part of education I really enjoy.

Myself, I love to read. One thing I do is I subscribe to newsletters; some people do it in a different way. But that way, I can look through generally aggregator newsletters in academic fields which I'm interested in so that I can look through; so; here are some articles that may interest you. And I go look through, and I'm like, yeah, that one does interest me so that I can keep up to date on the state of the industry or on nascent industries, you know, things that are starting to form. I'm personally interested in machine learning, so I follow that pretty closely. I follow that.

I've also taken courses online in topics that interest me, both alone and with others. And I will say that taking a class with somebody else, you are far more likely to finish it because there's the social aspect to it, so I love that.

DAVID: Absolutely.

MIKE: And it is true also that just in the course of your job, you will encounter things, and you shouldn't be ashamed to go out and learn that as you're going. So that's a quick sampling of some things that I do.

DAVID: I love...there's a thing that happens to me occasionally in this field. When I'm talking to people, I talk about being an autodidact and learning and growing on your own, like, motivating yourself. And I actually hear people come back and tell me, "My boss tells me I don't pay you to learn." And I just laugh and laugh and laugh and laugh and laugh because I ask them, "What are you working on?" Because in software, what your boss hands you pretty much every single morning is, here's the thing that's never been done before, go do it. Uh, you sure your boss doesn't pay you to learn? Your job is literally to learn.

MIKE: Absolutely.

DAVID: I said at the top of the call that I had kind of a weird insight into this because of something that I had been looking into. And I was going to try and hold it in my back pocket, but you stepped right onto it, Mike, with talking about children. There was a fantastic video...I'll have to dig it up. If we've got show notes for the show, I'll put these out, but if not, you can search for it on YouTube.

It's a discussion that Neil deGrasse Tyson had in an interview. And he got asked, "What do you study? What are you learning right now?" And he kind of goes off on this tangent about the things that he's studying, about how he's interested in studying how people learn and how people change the way they think. But he veers into this beautiful, beautiful anecdote about how as an educator, he feels that it's his job to spend energy teaching people to love experimentation. And he needed to illustrate what does that mean.

He's like when you have a six-year-old pushing a tray table with a glass of water on it, and that glass is shaking, that's an experiment. This child is doing an experiment. If I shake this, it tips, it falls, the glass breaks. That's an experiment. I have a situation. I have a stimulus. I have a response. And so many of us, the natural instinct is don't do that, don't do that to the degree that it's just simply a day-to-day occurrence. Yeah, sure, I mean, you got to live with your kids. [chuckles]

But if you can view it from the point of view of this is an exploring creature conducting an experiment on the universe outside of them, and I want to encourage them to gather prima facie evidence, first-hand evidence on the universe around them, you let them break the glass. And you say, "Okay, what did we learn?" without shaming them, not the "What did we leaaarn?" No. But literally, "No, seriously, what did you learn? Tell me what you learned from this."

Or if you must be preventative in this, step in and say, "What do you think you're going to learn? What do you think is going to happen here?" And again, not to do it in a shaming way but to do it in an encouraging way, and that takes energy. I mean, you got to go buy a new glass [laughs] and then replace it. You got to clean up a mess if the child's too small to clean up broken glass.

But that child goes on to become a scientist or an explorer because they end up with a first-hand thirst for exploration and knowledge. And they also gain this core belief that exploration is safe and wonderful rather than damaging and hurtful because I got yelled at when I broke a glass. I was blown away that that's what Neil deGrasse Tyson is studying right now is that level of learning. And I thought, wow, he's literally learning how to learn and how to teach people how to learn. That's cool.

MIKE: We could probably spend a lot of time talking about the joy of exploration that children have. And maybe that could be a guiding principle as we're talking about this topic. What do you do to stay up to date? Well, be curious. [laughs] If you've got curiosity, feed it because if you don't feed it, it will kind of atrophy, and you'll find yourself burned out and bored. But if you feed it, then you're going to find your career pivoting, and you're going to be in that job that didn't exist ten years ago because you'll have gradually migrated and followed your curiosity into something new.

DAVID: Absolutely. What are things that we can do if not to, I mean, I think it's like a foregone conclusion for us to say we got to keep learning; we got to keep growing. Are there conscious, explicit things that you can do? I know that the Atlas team at Acima there's dedicated time on the schedule. This is learning class. This is time for us to sharpen our skills. Skills Clinic is literally what it's called. And it's an invested amount of time. I've not worked at a place that had that dedicated, so most shops, in my experience, don't do that.

What can you do to encourage those around you to learn or to create? I just realized I'm trying to trick you into giving me the answer that I want. And the answer that I want you to give me is that if I go create the environment where everybody's learning, then I get to learn too. So I'll throw that out. But what can we do to create an environment of learning where other people can learn, grow, and continue, and we can learn, grow, and continue? And who cares? Not just for you getting your next job but how is that going to benefit your employer here today?

MIKE: You dropped a couple of hints there. [chuckles] The first is you said, well, you do the skills clinic where you dedicate your time every day. Well, not everybody out there is going to be able to walk up to your boss and say, "We're going to start taking an hour every day learning stuff." Now, a lot of you probably could because your boss might be like, "Okay, that sounds great. I want better-educated employees."

Sometimes that might be a little overwhelming, like, wait, what? What about productivity? But you don't have to start that big. Start a book club. Start a book club. Now you are working with other people, which will help keep you motivated, and you can do that together. Or go find some people who are interested in a class. Go take it at the community college, or a local university, or online. Most of those are get together here. There's a recurring theme. [laughs] It helps keep you motivated if you wanted to make space for other people.

There are things that you can do, I think, wherever you are to make that kind of space. You can say, "Let's read a book together. Let's do a book club, and then every week, we'll talk about it." You're not taking very much time. You can even do it on your lunch break. You can make that space. "Let's go take a class," and then you swap ideas. [laughs] You give each other support like, "Hey, have you done homework yet?" [laughs]

You can find somebody who is starting their career or who wants to start their career and say, "Hey, want to get together at lunch, and I'll help you out to learn some of this coding thing?" or this data thing, whatever it is that they're wanting to pursue. Well, now you have a recurring opportunity to get together and mentor somebody. And as you mentor, you learn a lot.

I threw a few ideas out there. I'm curious, other people I think have been involved in these ideas and more. I'm throwing these out because I've been involved in all of these things before. I mean, I've done these things. Other people, have you done other things, or if you participated in the kinds of things I mentioned, how did it work out?

RAMSES: One idea that we incorporate quite a bit, probably in our organization but specifically on our team, is encouraging the idea of pair programming and pair reviewing, which I think helps to promote a healthier understanding of how things work or should work, or can work and just alternative solutions. And overall, just better discussions and better collaboration, which I think is important. Each of us is limited by our experiences. And we're limited to our current understanding of things. So gaining someone else's perspective or insight and experience is tremendous.

AFTON: I agree. I think our pairing, which has been highly encouraged on the Atlas team for quite some time, is a great way to have this ongoing mentoring environment, which then helps everyone to continue learning because everyone is teaching. Those who know more are teaching those who know less, and those who know less get to have a chance to try and explain things to someone else, and that develops their skill. I think that's a wonderful thing that we have on our team.

I want to go back just a little bit to what Dave mentioned earlier, which was our skills clinic, and how that's been in place for a while as an opportunity for us to spend time sharpening our skills. And the funny thing is, and Mike can attest to this, is we started that skills clinic kind of as part of an internship. But after the internship ended, it was really hard to get the skills clinic to keep going. It was hard to get developers on the team to attend and take advantage of it.

And even before the skills clinic, the take an hour a day to sharpen your skills was talked about, encouraged. But I found for me; it was really hard to take that time. Even though it was being handed to me on a platter and said, "Do it," it was really hard to take the time. And it has been always really hard because when you're in the middle of a problem, it's hard to set it aside and go do something else. Context shifting is hard. You always just feel like I need to get this done. I need to get this solved. I need to get this out. Sometimes there's pressure to get something out quick. Sometimes it's other people are relying on me.

There's just always a lot of weight going and pressure to get work done. There's always so much work to do that we can never catch up, which I think contributes to that. So recently, I realized something that has made a world of difference in me, taking that time to sharpen my skills as often as I can. I don't know that I'm getting an hour a day, but certainly, more than I was in the past. And what that was was thinking about my career and what I'm working toward personally.

So I actually took this little online course on LinkedIn learning about...I think it was how to choose or organize your priorities when everything on your plate is a priority. [laughs] And so it was breaking things down into, well, you have to think about what's urgent, and what's important, and do the things that are urgent and important first, and then the urgent but not important or important but not urgent. They had this stack of how to decide what to do first.

And then it also talked about another way to decide and get things done that you keep wanting to do but haven't figured out how to make happen is to think, okay, where do I want to be a year from now? Where do I want to be in my career? What do I want to have accomplished? Where do I want to be five years from now? And I was thinking a year from now; I want to have better technical skills than I have today. And I want to have written a lot more code and have a lot more experience in our codebase.

And in my newish position as a team lead, it's been a lot harder to find time to be writing code and to be learning. But when I said okay, a year from now, if I haven't progressed in those two areas that are super important to me, I'm going to be really frustrated with myself. So the only way to make that happen is for me to make sure that every day starting yesterday [laughs], I prioritize that.

And sometimes, I have to take something that is a priority and say I'm not going to do that for one hour. And instead, I'm going to spend some time sharpening my skills or working on a ticket because that is also a really high priority. And that's made the difference for me is knowing what my goal is for myself a year from now, five years from now.

DAVID: That's amazing. That's awesome. Thank you. There are so many things you just dropped on there. I'm writing frantically. I love that idea that there's always so much to do. I would amend that and say there's always too much to do. And just like you said, when everything is priority one, nothing is priority one. Well, guess what? You can weaponize that to your advantage.

If you can't stop to improve your skills and invest in yourself because you always have too much to do, then stop and invest in yourself because you're still going to have too much to do, whether you stop and invest in yourself or not. And a month from now or a year from now, if you have increased your capacity a month ago or a year ago, you're reaping the benefits of that.

AFTON: Yeah, absolutely.

DAVID: You said having a goal, and it reminds me of a thing I did in...oh God, [laughs] somebody told me once that "I hate when programmers stand around telling war stories." This is totally a war story. I'll make it quick. Back in like 2006 or 2007, I had gotten into Ruby on Rails, and I was really excited about it. But all the work in my hometown was PHP. And I had a customer approach me. I was freelancing back then. I had a customer come to me and said, "I want you to build me a website from the ground up."

And this was an old customer. We had a really good trust relationship. And he also paid me miserably. [laughs] He wanted old rates from 10 years ago when you didn't know how to program. And I negotiated with him that I will do this for you, and I will do it at the old rates, but I'm doing it in Ruby on Rails. And he didn't program, you know, I basically told him, I'm going to do this with a left-handed metric spanner, and he was like, yeah, okay, knock yourself out.

And because I had that as an explicit objective that I want to get professional experience working in this, I was able to just gin it up out of whole cloth and basically say, I'm starting this project professionally because I'm a consultant and I can do that. And then, a year later, when I got the opportunity to work in Ruby on Rails at a company, and they were like, "Well, what experience do you have?" I'm like, "I've been doing it for the past year." And that was super, super useful.

MIKE: Interesting. My intro to Ruby on Rails was somewhat similar. I was at a company doing Java. They said, "You know what? We need to use an interpreted language. We want the flexibility and speed that we've seen other people have in interpreted languages. So you're going to do PHP." And I'd done quite a bit of PHP kind of on the side. And I thought, given the state of that language community at the time, I thought, if we do this, we're going to have a horrible ball of mud in no time flat. I need to use something that has a framework and organization that we can work with.

And I heard a presentation about Ruby on Rails at a Java Users Group. It was like, "Yeah, there's this new framework in beta called Ruby on Rails." So I went and wrote the seed of our rewrite in Ruby on Rails over the weekend, kind of learned the language and the framework. I spent a long weekend. I came back, and I said, "Okay, well, I've got this prototype. What if we try this?" Like, okay, I mean, you've already got it; we might as well. [laughs] And we ran with it. And I've been doing it ever since.

DAVID: That's awesome. Rails had that sneaky underdog thing. There was that seminal post by DHH, "Build a Blog In 15 Minutes." I've seen that happen as well where somebody says, "Oh, let's switch to Rails." And they're like, "Well, what's the start-up cost?" It's so great to be able to say, "I wrote it on the car over here today," or, "I wrote it last night." The start-up is done. Now all that's left is all the really hard work. But you don't tell them that. You just tell them, "Oh, look, the start-up piece is done. That's half the work," right?

MIKE: [laughs] It's true. I can say that that application we rewrote ended up having one-tenth the number of lines of code, and it did more. But that doesn't necessarily mean better. So, I mean, I'm not trying to be a framework snob or anything here, [laughs] but there were some definite pluses that came from it. But yeah, exactly; if you come with the prototype, it's a lot easier to sell your cons.

DAVID: There's a line count that, in my experience, Ruby has about somewhere between a 3:1 and a 10:1 ratio of line count. Prior to Rails, I was used to working on C++ projects with half a million lines of code and then PHP projects that had 100,000, 150,000 lines of code. And now, if I see a Rails project with more than 30,000 lines of code, I get scared because that's a big project because you can do so much.

And there are trade-offs to that. It's a lot harder to tell your manager, "Oh, yeah, I wrote 1,000 lines of code today." It's a lot harder to do that in Ruby than it is to do it in C++ because there's just so much boilerplate. You get 900 lines for free.

MIKE: And you need to recognize there's trade-offs as well. We are talking about interpreted languages. In Ruby specifically, you don't get some of the type checks that you get from other languages, and there are some real trade-offs there. I'm thinking TypeScript is overtaking JavaScript. It compiles to JavaScript; I mean, it's the same language, basically. But people want to have that type safety because it avoids certain kinds of problems. So, I mean, absolutely, there are trade-offs but interesting ones. We can really get into this. [laughs]

DAVID: Oh yeah, I can drill into this really easily. There's a concept that I've seen, well, actually, this is a good example of learning, and then all of a sudden...what I will say about studying to learn something is don't be afraid to chase a tangent because that's where all the marrow is. That's where the juiciest tidbits are is when you're in the middle of something, and then, whoo, we go off down this sidebar. But when my ADHD fires way too hard, I look around, and I realize everyone's eyes are glazed over because we're seven tangents deep.

And there's an idea where those of us coming from old statically-typed languages we had all this upfront checking that the language had to do. And that cost ceremony, and that caused us to slow down. And it was very frustrating, and we wanted to go fast. And these interpreted languages came along, and these dynamic languages, and it's like, oh hey, look, we don't have to do our upfront checking. Well, then our programs blew, so it's like, okay, we need to do unit testing. We need to test at the other end.

If you're not going to test that all the types are correct, then you have to test that the program behaves correctly at the end of it. And there's a really phenomenal thing in the industry where you can see some people going; I don't have to check upfront, but I'm too lazy to actually come back around and test at the end. And those people, bless their hearts, their co-workers are the ones who are saying, "Let's maybe go back to statically typed. I think it would be okay if Jim could not write software without enforcing something on either end of this. Let's hook into somewhere.

MIKE: We should do an episode on typing.

DAVID: Oh yeah. I can do about 110 words per minute.

MIKE: [laughs]

DAVID: Oh, wait, wait.

MIKE: Ramses mentioned pairing. That's really interesting. You didn't say formal study but getting involved with another developer so that you're sharing ideas with each other. Kind of continuing on this idea of tangents, those of you who have learned something pairing, do you usually learn something that you were expecting to learn when you're pairing with somebody?

DAVID: Never. I'll let somebody else take the question, too, though. [laughs]

RAMSES: Yeah, not always. You never really know what you're about to learn. Like, it's not really super formal. So you just get together, do some discussions, and throw out different ideas, different solutions and see what you come up with. It's always an interesting and unexpected experience.

MIKE: Yes. So you set up to solve a problem. You're pairing to solve a problem, and you end up learning something. I was talking with some people about recursion earlier this week about a function calling itself. And we ended up talking a good deal about memory management, about how your computer manages memory, and the operating system, and addressing, and pages in memory, virtual memory, kind of far afield from recursion.

But we talked about that so that we'd understand how that stack of function calls eventually is going to run out of space. So we went in with one goal in mind and ended up somewhere very different. But they're both useful. It always happens that way if you let it happen. You leave room for that spark.

DAVID: Yes, it's very important to not fall into the trap of trying to predict the spark. Or rather, you can absolutely predict that the spark will happen. I've done podcast episodes where everyone is sitting around going, "What are we going to talk about? I have no idea what we're going to get out of this." And I just told everyone on the call, "It's fine. Just sit down, relax. It will happen. Trust me; it will happen." Banking on the spark happening is absolutely doable.

But if somebody sits down and says, "What are you going to learn today?" It's really hard. Mike, you might have sat down and said, "Well, we're going to learn about recursion. We're going to learn about creating base cases. We're going to get into mutual recursion where this function calls that, and that function calls back into this other one," and blah, blah, blah, and down the road, you go.

Nowhere on your prospectus would you put we're going to learn about how memory management, dah, dah, dah, that the heap is well managed and the stack is not, and dah, dah, dah, and down you go. If you lock yourself into that predictive deductive thinking rather than walking in open-armed and ready for inductive learning, you'll cut yourself off from your own creativity. What's the rule from writing? You can't create and edit at the same time. You can't be an editor for your writing while you're writing everything you're writing. I've missed the conversations where I throw three metaphors at a problem at the same time; there you go.

MIKE: But we went there, this idea that pairing is a really great way to enhance learning. You don't go in there necessarily with a goal in mind. Instead, you create an environment where that curiosity and exchange of ideas can happen.

AFTON: I want to say that this learning from pairing is not limited to learning additional technical skills like some new coding trick or even a new design pattern or something, which are definitely valuable. But one thing I also get from pairing is getting to see how someone else's process works. What kinds of questions do they ask to navigate the problem we're trying to solve? Where do they go in the code? How do they figure out what questions to ask and where to look? And what are the steps that they take from start to finish to solve a problem? I think processes are super interesting, and having a good process can make you more effective.

This kind of goes into what I was thinking about what I do to continue learning. I realized also recently that I have two different areas of learning that I focus on; one is on super technical skills, learning a new language, or refreshing my Ruby on Rails knowledge, or even studying algorithms, which we've been doing in our book club. But on the other hand, I'm also studying how to manage projects, how to communicate well with people I work with, like on my team. Right now, as a leadership, we're starting crucial conversations and learning about how important it is to be able to talk to people and communicate well your intentions and your ideas, and organize your thoughts and respectfully, and all those things.

And we mentioned in an earlier podcast episode; development is so much more than just writing code; we do so much more. We are teammates. We're working with other people. We're organizing projects. We need to know how to manage our time to be efficient and effective. And so I also study time management and figuring out your priorities, how to figure out your priorities, leadership skills, communication because I believe that all those things are also going to make me a better developer, a better teammate, more effective in my career.

DAVID: There's a thing...I believe it's called the synthesization step or integration. I can't remember. There are steps to learning ideas. And for me, the exciting thing is near the end when all of a sudden, you find out that these wildly disparate fields of study are 100% overlapping where you're getting into time management, and you're like, okay, this is important, and it's essential. And I have no control over where it's going, so I have to focus on the process and just let it go where it needs to go. Or this other thing is not important, but it needs to be done. So I need to focus on what is the fastest way to get to this outcome?

And then weeks later, you're having a conversation with a co-worker, and you realize I need you to write this to this API. I don't want to talk to you about your feelings about it. We'll do that at lunch. I just need you to do this, and I need it done quick. We've got this other deadline. It's like, I need to be efficient with you. I need to focus on the outcome, boom, boom, boom.

And then an hour later, you're talking to somebody else, and you realize they are wide open vulnerable. And you suddenly realize I can't be efficient right now. Efficient is the most deadly thing I can do to this conversation. I have to be effective in how I communicate with this person. And so you're like, you know what? I'm clearing my schedule because this is important, and I don't know how long it's going to take.

When you see those parallels, you study how to communicate with people. And then a week later, you're writing some code, and you're like, oh, how do I document this function? And all of a sudden, you realize, oh yeah, I know exactly how the person reading this...I know what they're going to be hungry for, what they're going to be looking for. I'm going to document that, or I'm going to write a unit test that expresses this.

And it's kind of nice to have somebody come back and find you and say, "I love that test that you wrote because I could not figure out what your system was doing until I saw that test. And all of a sudden, I could see the through line in all of your software." That's amazing. I've had that happen once in my career, and I'm still bragging about it on podcasts today.

I have a weird question for the group. You know me, I love weird questions. What is the weirdest, most out-there thing that you have learned that you've been able to bring into a professional situation with benefit? I mean, obviously, some of us bring weird stuff into the office just for the sake of bringing weird stuff into the office, and it doesn't always go well. But is there something that you guys can think of that you're like, I did not expect to use that at work today?

RAMSES: Yeah, that is a weird question, and I don't know if I have a good response for it. I spend a lot of my time trying to learn new things to improve my workflow and to improve my knowledge. I don't know if I have a better response for any weird things.

MIKE: I'm trying to think of a specific example. It feels like everything that I end up studying ends up crossing over. So here's a recent example. I'm going to take my kids out trick or treating. We'll probably release this next year in March or something. You're like, wait, what? [laughter] But we're recording this in October, and here in the U.S., we're doing Halloween in about a week. And we were talking about how to do a quicksort earlier this week, or I think it was last week. Recently, we were talking about how to do quicksort.

And I was trying to think about how can I represent the intuition behind this idea in a way that you can get your head wrapped around an event or two? And I thought, oh wait, okay, so it's Halloween. And you've just come home with your big bag of loot. You got your big bag of candy, and you want to know which is the worst candy, which is the best candy. You want to trade with your sister. And so you want to make sure you know that you're trading the bad stuff, keeping the good stuff. You want your tootsie rolls to be given away. You want the big candy bars. You get the idea. So you've got this big bag of candy. You want to sort it.

Well, how do you go about doing that when you got a whole big bag of candy? How could you possibly go through and sort that in a reasonable way? Well, here's what you do. You dump out your candy on the floor, and you pick out a random piece. And you say this piece is going to be the decision piece. It's going to be the pivotal piece. And I'm going to take everything that's worse than that piece, and I'm going to put it in a pile to the left. And then take everything better than this piece, and I'm going to put on a pile to the right. That's all you do.

So I'm just going to put the ones worse than this to the left, better on the right. That's an easy decision to make. And I'm going to put this piece in the middle. Well, then I'm going to take the pile on the left, and I'm going to do the same thing. I'm going to pick out a random piece, and I'm going to take everything that's worse than that one and put it on the left and everything better than it on the right.

Well, now I've got three piles. And I'm going to do that to each of those piles and then any piles that come after that until I have gone through all of my piles, and all I have is a line of candy. And it's perfectly organized from worst to best, left to right. That is the Quicksort algorithm. For me, that illustrated, in my mind, in a way that I'm never going to forget. And that was a huge leap. It wasn't even a technical field at all. [chuckles] It was just something that came from life. But these intersecting ideas happen all the time, and being able to connect them gave me a huge aha moment.

DAVID: That is awesome. Do any of us have any thoughts that we want to throw out on this? Is there something that you wish you could have said at this point that you want to get in?

MIKE: Keep the joy of curiosity in your life. Find a channel where you can keep that curiosity alive. And I think it will serve you really well.

DAVID: For me, I would say don't be afraid to go way, far afield with things. If you want to be a better programmer, study a parenting book, pick up the guitar and learn music, go hiking, learn how to hike better, actually study hiking instead of just throwing at it. Pick stuff way, way, way out, and you're going to find parallels to the thing that you do every day. And it'll surprise you.

RAMSES: Yeah, that's a pretty good way to end it. Try to learn things that you're curious in and also things that scare you. [chuckles]

DAVID: Yeah. Well, all righty. Thank you, everyone. This has been fantastic. I've missed coming back and hanging out with you guys. I'm enjoying my time over in the database land, but I missed the front-end, back-end work. Thanks, everyone, for coming.

We talk about a fun topic–teaching kids to code!

Transcript:

MIKE: Welcome to another episode of the Acima Development Podcast. I'm Mike. I'll be your host again this week. And we've got with us Eddy, Ramses, and Tad. Today is a fun topic. We're going to be talking about teaching kids to code. I thought that I might start the session [laughs] with a personal story, a couple of them actually that I think are relevant and will help inform our discussion.

I remember my first experience coding as a kid. This is way back in the ye olden days of yore [laughs] when computing was different. When I was in about third grade, we got to use the school computer because the school had a computer, and classes would take turns playing with it. We had Logo, which is software that allows you to move a little turtle around the screen. You code it to walk around the screen. That was cool. It was real-time feedback.

You tell it to move; it moves. And you tell it to move again; it moves. But we learned that there was a way you could go into a back screen where you could type in loops. And I remember playing with that and thinking it was the coolest thing ever. [chuckles] I wanted to do that all the time. But I had to use my 10 minutes of computer time on the shared school computer, and that was it. [laughs]

And I didn't really get to use a computer again for some time, except that I did have a couple of friends who had coded in BASIC and taught me some things, which I also thought was cool. I remember that in sixth grade, the teacher tried to show us how to code. They had the BASIC environment there. And I thought, oh, I remember how to do this. And I wrote line 10, and I had it print out my name, and line 20 GOTO 10. And I ran it because I remembered how to do that. And it just started printing my name endlessly.

And the teacher, who was really unfamiliar and was just following a set of instructions and had no idea how to undo that couldn't stop it, had to restart the computer. And by the time the computer got restarted, our computer time was done, and we had to go back to class. [laughs] So I ruined the coding session for everybody. It wasn't a high point, [laughs] and the teacher was not at all happy with me.

I can tell some other stories of learning to code later. But there's some commonality there. [laughs] Coding was fun when I had a chance to have fun. And it didn't work out very well, and there weren't resources for me to play. But also, there wasn't somebody around who could give me some guidance. The teacher wasn't able to find any help. It meant I did something fun and then got lost and frustrated, and that was kind of the end of it for everybody. And unfortunately, I ruined the day for not just myself but a bunch of other kids.

The kids love to explore. Kids explore by nature and want to go out exploring, and given the chance to do that in the right environment, will tend to latch on to it if they get the support that they need. With that context, let's go on and talk about some ideas for helping kids to code. We were talking a little bit before we started today about some experiences other people have had teaching kids to code. I've myself had a decent amount of experience.

I've taught several kids to some degree how to code, including my own and those of friends and relatives. So I've got some background doing this, have some ideas but certainly don't have all the ideas. There's so much out there, and there's so much science of teaching that I'm sure there are all kinds of things that I'm missing. And I'd love to hear what other people have to say. First of all, any thoughts based on my story or thoughts to begin our podcast?

TAD: Yeah, as I was thinking about this, there are maybe three things that really interest me when people talk about this kind of stuff because I'm curious how they got started. And those three things are, how did you first get access? What was your hook? What was the thing that got you interested and got you started? And the third thing is, who was your mentor, or who was the person who came along and gave you the nudge that got you in?

Because as I was listening to your stories, I'm like, these are some common elements that I've noticed in a lot of people's experiences. And so I'd be curious to hear from Eddy and Ramses because Mike, you, and I are both in our 40s. And so that first one, how did you first get access to a computer? Is [laughs] because they weren't ubiquitous when I was a kid, right?

MIKE: No, they weren't.

TAD: I remember when every teacher in my elementary school...I think I was in fourth grade. Every teacher got their own computer for their own classroom, and that was big. And you'd hear about computers, but they weren't really common and really accessible. So I'd like to hear other people's experiences; just how did you get access? What was the hook that got you interested? And who was the person who gave you the nudge? Maybe you don't have those three, but I've found those to be very common elements when talking to people about how they first learned or what got them into it.

EDDY: Actually, it's kind of funny; you kind of struck a chord with me there because I'm like, dang, when did I get interested in that? To give some context, I'm hitting 30. And back in elementary school, there wasn't high-speed internet, so the only way we had access to the internet was connecting to the phone cord. And you had to switch back and forth between taking a phone call [laughs] and connecting to the internet. So it was like dial-up.

And the problem was that cell phones weren't very prominent at the time. My mom would always go and scream at us, and she's like, "Hey, disconnect from the internet. I need to make a phone call." When she wasn't on a call, we had no access to the internet. And so we dabbled around, my older brother and I, on how to change elements in HTML. And seeing little buttons and text being changed and rendered was my first exposure because that's the one thing I could do without internet access.

MIKE: So the computer [laughs] was dial-up internet. The hook was being able to make changes in HTML so you could make a webpage. And is it your older brother who got you interested?

EDDY: Yeah. Initially, it was him. And he kind of just flew with it for a while. I kind of just sat back and watched him modify some tags. But it was something that we could do while not having access to the internet. [laughs]

MIKE: What about you, Ramses?

RAMSES: I'm in my late 20s as well. I've always just been around computers. I think I was first exposed to computers when I was like five, probably. We got a home computer for Christmas one year. But yeah, it was a lot of fun. I don't really remember being super interested in coding when I was really young. But I think I was just always intrigued by technology and building things. Mid-20s, I got more interested in learning coding and taking it a lot more seriously. So I really enjoy it because you get that feedback like you mentioned. And it's great being able to build things and to build something and know that you're helping someone.

MIKE: I'm with you on that feedback, that moment you realize you don't just have to be a consumer of what the computer gives you. You can make that a two-way conversation and ask this tool to do things for you and have it do that, and it's just magical.

EDDY: Was there anybody who kind of nudged you into it, or are you kind of self-taught, self-discovered?

RAMSES: Kind of a combo, like, self-motivated. I don't want to take all the credit myself. [laughs] I mean, I'm self-motivated, but I think I learn a lot from other people. There have been a lot of mentors that I've had. Mike was a prominent one early on and still is, you know, Afton, Tad, a lot of other people.

TAD: My curiosity is, were you thinking about taking this track when you first started working for Acima, or was it you found a niche in QA, and then from QA, people kind of nudged you over into development?

RAMSES: Yeah, it was exactly that. When I was in application support, I found kind of an opening that expanded my interest in learning software development. And I don't know if there was any single person that kind of pushed me. There were probably multiple. One of our old product managers, Jeff Madsen, was a pretty big proponent of that. Mike Challis was a proponent of that as well. I think he nudged me a little bit.

MIKE: Something interesting to me about that is we all have different paths here, those who picked it up more as adults, and I'm going to talk about you, particularly Ramses. A lot of people potentially listening to this who may be coming from a background where like, well, yeah, I don't have a traditional computer science background. I've never really done coding, but I've started doing a little bit of work.

But there is this...not really the back door or the front door, like, the side door [laughs] where you're at someplace that's...it could be a business. It could be something that's not even specifically a business but any organization where you have an opportunity, maybe unexpectedly, you just start doing this work. A lot of times, people think, well, this is just kind of this side thing that maybe I'll pick up a little bit. But that can be a real gateway into a career.

And I've known a lot of people now who've gotten into the career not by saying, "Oh, I'm going to go to school. I'm going to get a four-year degree, and then I'm going to go do an internship, get a job," like have this really clear linear path. A lot of people don't come in that way. They are in application support, and they get an opportunity to expand their roles, start doing some coding, and eventually, they become a full-time developer. And this applies in actually kind of diverse fields.

There are biologists who have found that to understand their data better, they needed to learn how to do some coding and machine learning. And so they became coders and started building up the tools to do better analysis of their data. Now they're developers and biologists. And the same thing applies to doctors or...those are just some that come to the top of my head that I read about. And these are kind of high-prestige professions. But there are some things that are less prominent that are also important.

But there are many professions that don't necessarily have a lot of visibility but have need for some sort of software. And if you can get in that a little bit, it's surprising just how much that need is there. And you can step into it, again, through that side door and find yourself with a fairly different career because you latched on to that and just kept on working on it.

TAD: Right. Yeah, I've met a lot of developers who came to it from one of these side doors, like you're talking about. Because it's really interesting to me, software is everywhere and really touches everything in our lives now: it's in your phone, it's in your car, it's in your...whatever appliance you're using to make your breakfast. [laughs] It's in your fridge, like, it's really surprising all the places that you find software now.

And it's interesting because I worked with a guy who was a physics major, but he's like, "Oh yeah, I had to model some things. And so I had to code some things, and I found out, oh, I really enjoy this more than I enjoy physics." I worked with a guy who was into accounting and uses Excel all the time. "Oh, I've got to write macros for Excel. Oh, I'm going to learn some more Visual Basic so that I can write better macros for Excel. Oh, I actually prefer writing macros over my regular accounting job." Suddenly, they became a developer.

Or I had a friend who was a journalism major in college, and he really liked to investigate and figure things out, and that led him to documentation and stuff, which led him into software development. So it really is everywhere. And it really is possible to transition from pretty much anything over into software development because it's so ubiquitous, I think.

MIKE: I agree wholeheartedly.

EDDY: I kind of want to touch a little bit, like, you mentioned before on this call that you were successful in teaching your kids how to code, and one of them is actually going to school for that. How did you engage or propose the idea to your kid? Because I'm sure you proposing that idea had some sort of influence.

MIKE: Yeah, that's a great question. It's a perfect segue into talking about what you can do specifically for kids. We've talked some about adults here more than kids and then a little bit with kids. There's the same idea of that hook and how people get started. My oldest, my son, he is now 18. He's going to...he's in college, University of Illinois.

When he was fairly young, I think the first coding that I exposed him to is that he would sometimes be working on math and want to have a better calculator than what he had. So he's working on his math homework, and he wanted to add some numbers together or do something like exponents, where it's a little more sophisticated, and you want to do a bunch of steps.

One thing about the way simple calculators work (I guess there are more sophisticated ones now and maybe even on your computer.) they usually perform the operations as you type them. So rather than being able to write out the entire program, you know, I say program but kind of the problem that you're working on and then execute it; instead, you do one step at a time. And it's very easy to lose context, and you kind of lose track of where you are. And you don't have a history of work that you can go back and check, which is frustrating. [laughs]

So I started showing him, "Hey, you can come up to this console and do some live coding and interact with the computer that way." I made sure to teach him several languages at once so he can see there's more than one way to do it. And they are pretty similar. I remember showing him Haskell, which is [laughs] a more obscure language but very mathy. And I said, "Hey, look, you can open this interactive console and just type in some Haskell, and you can get the results back." He's like, "Oh, cool." And I think I showed him Python and Ruby. All of them have the read–eval–print loop where you do interactive coding, or REPL, people will call it.

And I started showing him that, and he's like, "Hey, this is really useful." So he'd be using this. He'd pull this up on a laptop for his math class. So he could write out the problem, check that he had written down the problem correctly before he executed it. So unlike a calculator where you don't get to check your work, you can go back and say, oh, which steps did I do wrong here? And that was really helpful to him.

And once I had that hooked, well, now he knew that it was useful. Now he knew that there was a tool that he could use to make his life easier. And really, it wasn't super hardcore coding. It was just typing some simple arithmetic expressions. But that gave him the hook he needed to be able to start doing more. Beyond that, I started introducing him, when I had the opportunity, to some additional kind of sandboxes to play in.

And there are several tools I'd like to call out here. There's a popular one that we never really did use called Scratch, which is not too far from the Logo I used when I was a kid, where you can give instructions to tell an animated character or some sort of avatar or icon to move around the screen. And Scratch is popular. It's widely used in education. Probably a good option if you can find somebody who's interested in it. It just never really spoke to kids I've worked with. But there have been some other things.

One thing that most kids seem to love is Minecraft. And Minecraft has a huge modding community. Huge. [laughs] I know that there's a similar game, Roblox. There are a lot of sub-games in Roblox that people have created by coding them up. Roblox is kind of designed around having this, hey, you build your own mini-games community, and a lot of people have done that as well. So I think that's also another great option. If you've got a kid who's into Roblox, well, great, they can build their own games. I would strongly recommend something like that.

So my son really was into the idea of Minecraft. I showed him how to mod a little bit, and it was kind of daunting. There was a company who provided several classes on how to do the modding. He went through their program and really enjoyed it. And he built his skills by learning how to mod Minecraft. And once he had that, then he was able to...I showed him some Python, so he was able to start doing some Python.

Again, I signed him up for some other classes that he had some interest in, and he just grew and grew. He writes scripts now to solve problems that he has. Like, he wrote a little Python program to give himself flashcards so he can study for a Spanish class which goes back to right where we first started. It was useful for him. He was able to use the computer to do something cool. He was going to come back to it because it helped him out. All of those tools have been really useful.

There's another one that I've used I'd maybe like to revisit in a little bit. When I've talked to a group of people, that tool...and there are probably others like it. This one that I've used is called Sonic Pi. I believe it's open source. Honestly, I haven't really looked into it. But it's a tool that was designed to run on a Raspberry Pi to be really accessible for educators because you can run it on minimal hardware. And it allows you to do fun stuff with audio. You can code audio and so be your own DJ with writing code and write your own music, which is fun.

EDDY: That's interesting. You just found a way to engage them. And I think that's really important. In order for a kid to learn something, you make a game out of it and create activities around it to stimulate the brain. And that's really interesting, truly. And not only that, but sharing enthusiasm for their progress, I think it's important. That attributed to some of my little sister's advancements, too, the little she had. It was like, "Oh, you got your character to move like one pixel to the right? Oh, that's awesome." [laughter]

MIKE: Which sounds trivial, but it really is kind of awesome, isn't it? It really is this sort of magic that you can take this amazing device and have it animate things for you, automate tasks that historically was the domain of things that humans could do. And it may seem trivial to move it one pixel to the right, but can you imagine having to draw that by hand, trying to hand-animate anything [laughs] for that matter? The massive amount of tooling and experience that would be required to accomplish something like that would be prohibitive in almost all cases. Having a tool that can do that is amazing. And there really is a magic to having that character move a pixel to the right.

EDDY: You're like the puppeteer.

MIKE: Tad, I think you'd mentioned earlier that you've had some experience getting kids hooked on coding or giving them some experience. Do you have any tools or advice that you'd recommend?

TAD: It's hard because there are so many things out there. You almost need to find...well, I keep talking about the hook. What are their interests? There's probably some hook you can find that will get them interested. To be fair, coding isn't for everybody. There are people that... [laughs] my oldest daughter just started college, and she's going into natural resources and wildlife management. And she very directly told me that she wants to be outdoors, and she doesn't want to sit in front of a computer, and she wants to do certain things. And I'm like, okay, yeah, you're probably never going to be a programmer. You'll definitely be using computers for things, but coding is not your thing, and that's fine.

But I used to help kids just tweak mods for Minecraft. They were really interested in Minecraft, and they're like, oh, regular Minecraft is interesting, but, man, I found this really cool mod for Minecraft that I really like. And then they start using mods and installing mods, and then they're like, oh, maybe I can make my own mod. And so they want to make their own mod, but they have to find a book or a person or somebody that can help them with something like that. Just for a kid to make a mod, they're just like, errr [laughs]

I think it's just finding the right hook. It's interesting to me–a lot of kids come through video games where they're like, "Oh yeah, when I was a kid, my uncle gave me a bunch of games, and I was playing a bunch of games." And my uncle was also a developer, and so I asked him, like, "Can you make games?" And he's like, "Yeah, sure. You can make games." And he helped me make a simple game, and that's how I got hooked.

EDDY: Tad, was there an attempt to get your older daughter into coding?

TAD: A little bit. She had a lot of exposure to it just because her dad is a professional software developer. They did a few things in school, but for her, nothing really clicked. And so I'm like, you know what? Do your own thing. Follow your own interests. But for a lot of kids, it would click if you just find the right thing.

I think there's a common misconception that people have and kids have. It's like, oh, I couldn't program because I'm not really good at math. Well, it's true that math is really important for certain parts of software development. Like, if you're coding a really complex physics simulation, or you're doing protein folding, [laughs] or one of these things, you absolutely have to have a dual major in computer science and math or something like that.

But if you want to make just a website...I was talking to this girl, and she got into programming because she really got into The Sims. And she really enjoyed making custom objects and custom outfits and things for different people. And she's like; I would love to share this with the world. I would love for people to download all my objects and all my Sims clothing. And she got into WordPress because she needed to make a website to do this.

And from there, she got into PHP so that she could learn how to work her WordPress stuff a little bit more. And from there, she just became a regular general web developer [laughs] because she really enjoyed making objects for The Sims. That would be my advice is just figure out what the kid is interested in because there's probably something that is related that you can use to hook them. Because things like Scratch aren't maybe interesting for every kid. But being able to make a website and have your friend visit it and it does some animation might be what you're interested in, right?

MIKE: Absolutely. Or music. There's that Sonic Pi that I keep mentioning, or like you said, the Minecraft mod. [laughs] There's a wide range of things that are out there if somebody has some inclination that you can get them hooked with.

TAD: Well, one of the other things is some people come to it on their own. I think a lot of people need somebody they can model after or someone that will nudge them. Because I've talked to a few girls who are like, "I always thought computer science, programming, whatever, wasn't for me until I got talked into it by this other woman. And she's like, 'No, women can code too.'" [laughs] And they're like, "Oh yeah, well, cool. You're showing me that you can do it, so I could probably do that."

Or I've talked to a bunch of people who are just like, "Oh yeah, my uncle was a programmer, so I saw that he had a lot of fun with his job. So I thought maybe I can be a programmer too." I think role models are sometimes an important part too.

EDDY: Your kid, when you proposed the idea to start learning to code, how was the mom's perspective on that? Like, was she hesitant at first? Was she reluctant? Was she fully on board or committed? Because proposing coding to a kid can be daunting from like --

MIKE: It's an interesting question. So were my wife and I unified on this or was I proposing, and mom was like, "Ah, I don't know?" Is that the question?

EDDY: Yeah, exactly. Was she like, "Do you think this is the right idea?" [laughs]

MIKE: My wife has always been very encouraging of my career. My dad and his brothers worked in construction. My mom was a nurse. But I wasn't interested in nursing. But her dad was a handyman, so most of my role models were in the construction industry. And that affects the way you see your career path. [laughs] I did some school. I kind of ran out of money and went to make some more money and ended up doing construction-type work. I did a few different jobs in that field to make money.

And it took me a while to go back to school because it was hard to save enough. [laughs] But also, I didn't necessarily see myself as a coder. And my wife was always very supportive in that aspect, saying, "This is what you need to do." So when my son showed some interest, I think my wife was very much on board because she saw that it gave him so much potential. There's so much potential in pursuing that.

She was actually the one who went out and found the class for Minecraft modding and said, "Hey, let's go get this. This looks like a good option." And then, of course, being a professional here, [laughs] I was able to help him out with it. But I think she if anything, was more supportive than I was because she saw the opportunities that were available there and tried to encourage us to do that. And I think that that was really helpful and important.

She also encouraged also with my other kids. My second oldest...there's a big gap between my oldest and the next. My second oldest just turned 10. My daughter is seven going on eight, and she has shown some interest. So I've shown her some coding. She's done some stuff on Khan Academy. She played around with it a little bit. It was a little bit beyond her reach. And so we're giving it a little bit of space, but she's had a taste. Not everybody is interested. So my second oldest, I don't think he is really ever going to be that interested, but my daughter, I think, is. So I'm going to try to give her all the opportunities that I can.

EDDY: What I told my mom, like, even if they ultimately decide not to proceed with coding, I think it's a valuable asset to have in your arsenal.

MIKE: Absolutely. Well, let me ask this in a different way: how often do you write essays in your career? Or how often do you solve algebra problems or use your calculus if you took calculus? I'm guessing the answer to all of those is never. They teach it in school anyway because learning to write an essay and learning to do algebra teach you a way of thinking, of decomposing a problem into smaller parts and taking the time to craft a quality solution and to understand how to break up that problem into small parts.

And sometimes we forget that we learned that lesson, and we say, "Oh yeah, I'm just going to do it all at once," and we get frustrated and lost. But those skills are very much useful, maybe not in and of themselves but in teaching broader skills. And I think coding is very much that way as well. It teaches you problem-solving skills.

TAD: Even beyond that, it teaches you problem-solving vocabulary because I love to talk to other developers because I already have a shorthand for explaining the problem. Like, I could say it's X type of problem, or it's Y type of problem, or this is a certain type of approach to this problem. I've got all these words, and there's a very rich vocabulary that comes with understanding all these different problems and how to solve these problems that I wish more people had.

So I could say, "Oh yeah, this is a problem of this type." And they'd be like, "Oh, okay, now I see what you're talking about. If it's that type of problem, then maybe here are some of the solutions for that problem." I'm like, "Yes." [laughs] Like, it would be so nice if I could use my rich problem-solving vocabulary in everyday life, and people would just kind of pick it up and understand it. And I wouldn't have to stop and say, "Okay, here's a story. Here's an analogy. Here's a thing that explains why I'm about to tell you this."

EDDY: I do have a question for Ramses. Do you have any kids?

RAMSES: No. No kids.

EDDY: Okay. So I'm currently married, and my wife and I are in talks of maybe making our family bigger. My question for you is like, I'm sure you've thought...or if you do have kids, are you going to also approach them with the idea of coding?

RAMSES: Yeah, I probably would. I don't know if I'll have kids. [laughs] I think if I did, I'd want them to be curious and explore what they're interested in.

EDDY: Awesome, yeah. Because my wife and I have talked about that too, and I'm like, "Yeah, I think I'm going to expose our kid to coding, to the idea." She's like, "Are you sure?" Because she's super reluctant and she can't stare at a computer for longer than 10 minutes. And she's like, "Are you sure?" I'm like, "Yeah, totally." [laughs] I'm like, "I'm not going to shove it down his throat or anything, but have that as an option."

MIKE: Well, I think, like you say, it's an option. Giving people opportunities is different from cramming it down their throat, taking that cramming-down-the-throat idea, giving somebody this smorgasbord. [laughs] They've got, look at all of this feast that you can draw from. It is very different from holding somebody's mouth open and trying to shove something down there. If you try to shove something down somebody's throat, they're not going to want to eat. But if you present that feast in front of them, they're probably not going to think twice, [laughs] like, yeah, I'll have some of that. And providing that presentation and opportunity so they can say, "Hey, this looks appealing," is the key.

And Tad has been talking a lot about the hook, getting people involved in something they're interested in. Children very much...and I think this is maybe universal to people that children hone this skill. They can tell when somebody's trying to make them do something. And they know like, oh yeah, you think this is going to be good for me, so you're going to make me do it.

They realize that they have independent ideas, and they want to exercise their agency to do what they want. And so they're not going to respond to making them do something. But if you say, "Hey, do you want me to help you build a Minecraft mod?" Well, that's an entirely different scenario. That's like, oh, wow, really? I can make my own? You're giving them that feast.

EDDY: Or how about just saying, "Hey, you're not allowed to create mods."

[laughter]

TAD: A little reverse psychology. [laughs] Yeah, I briefly taught some kids really basic HTML. And I'd teach them a little bit, and then I'd see their eyes kind of glaze over. I was like, "Okay, well, here's how you can add an image to your page that you're working on. Here's how you can make the background color red," and then just let them go.

And suddenly, they're like, "Oh, man, I really want to add this funny picture from the internet to my personal webpage that I'm doing." I'm like, "Okay, cool. We'll download it, and let's see if we can add it to your page." "Oh, I really like the color pink. I want to make my background pink for my webpage." "Oh yeah? How do you think..." So you give them a little teaser, and then they're like, wait a second, I want to do this for myself.

And suddenly, they're learning the hex code for pink [laughter] where before you're like, here's hex codes and dah, dah, dah, and they're like, er. But you give them a little taste and a little freedom, and suddenly they're eager, and they're teaching themselves. And you're like, oh yeah, here's a little online color wheel or whatever, and see how you can pick a color and see that there's a code next to it. You could choose that color and copy that code, and then you can make something on your web page that color.

EDDY: You see, Tad, I initially started with that curiosity too. I was like, oh yeah, I want to add a link to another site. But there's a huge gap between learning how to do an inline href tag to doing some CSS styling [laughs] to adding some logic, one jump into another. And there are super huge gaps in between. And that's what initially turned me off the first time, which was like, well, it's like, what are variables? This is too hard. [chuckles]

TAD: Yeah, I think that's why you need someone to come in and help kids over those gaps. I was talking to a guy, and he's like, "I really wanted to make a game when I was a kid. And so I just opened up Notepad, and I started typing text into a thing, and I just saved it as .bat," or something. I forget how Windows works. But I think that's a batch file or something. And then he tried to run it. And he had just typed in, like, open a window, do a thing. [laughs] He just did it in English because he knew that you could tell computers things. And he knew that these certain types of files could make a computer do things. But he had no concept of programming.

And as a little kid, he tried it, and then nothing worked, and he just got discouraged. And it wasn't until years later that he's like, "Oh, [laughs] let's figure this out." But how cool would it have been if someone came along and was like, "Oh, I see what you're trying to do. Let's start with something real simple and work up from there." Somewhere there's a point where they show the interest, and they take the initiative to act on the interest. And you need to be there to catch them when they can't figure something out, or they get discouraged and be like, "Okay, let's fix it. And let's take you up barely to the next level."

MIKE: You hit on a couple of things that I've been thinking about through this whole thing. You need to have somebody there. Presumably, most people who are listening here and all of us here have done some coding professionally, or maybe you've just dabbled in it a little bit, but you have some knowledge. I'm thinking about what Ramses said. Well, he doesn't have any kids. He might not ever have kids. That's true of a lot of people. [laughs]

But that doesn't mean you're not around people, around children, or maybe an adult who is wanting to grow their skills that needs that person to provide some scaffolding for them to help them get over that gap. And we can do that. We can be there and provide that bridge so they can get over those big hurdles and get to where it's fun again. And I think that we should be looking for those opportunities because, well, it's important, but it's also rewarding. It's rewarding for the person who's helping.

One other thing I thought about that you reminded me of earlier, Tad, is there's a nationwide organization, I think is what it is, called Girls Who Code. They provide get-togethers and resources and mentors for girls in particular, who are often underrepresented in this field, to see those heroes, those role models that they can see themselves in. And if there's a girl in your life who has some interest, there are some really good resources out there to help them see themselves in that role.

TAD: Yeah. I've got two daughters. And that, I think, really opened my eyes to a blind spot that I had, meaning the first time I was going to play some games with my daughter, she's like, "Why can't I play as a girl?" I'm like, "Oh, wait, what?" [laughs] She's like, "I want to play as a girl," and I think we were playing Minecraft. And I'm like, "Oh, I guess Steve is the only option right now."

They added skins, and we helped her design a female skin for her Minecraft character. And she was just thrilled her character could have long hair and run around and whatever. Yeah, I think some real holes where girls don't want to play the game...I go back to this because a lot of guys that I know who became developers started out doing games stuff. But the girls didn't want to kill a bunch of things and save the princess, like, eh, [laughs] that has no appeal to me at all.

There's this game that my daughter loved called Aquaria, where you're this mermaid creature, and you sing different songs to create different magical effects. And you swim around in this underwater world, and I'm like, oh yeah. And this kind of goes back to the right hook. My daughter got interested in games. She got interested in computers because I found some games that appealed to her interests. And sadly, I think that's still tricky to find for girls.

MIKE: I think it is, but there are things out there. We got to kind of make that extra effort, right?

TAD: Yeah.

MIKE: Making some extra effort to make sure she gets those opportunities to see herself.

EDDY: I've always just been curious on the psychology behind child prodigies who have this nature, like, this knack of being able to pick up coding. And I saw a video on YouTube about this eight-year-old [chuckles] who was developing iOS apps and brought their family out of poverty. So I've always just been curious on the psychology behind what makes that kid different. That may be a topic for another time.

MIKE: Yeah, that is a topic for another time. But I will point out that if you've got a prodigy, you've got somebody behind them who's been helping them get there.

TAD: Yeah, even a prodigy needs access to computers and access to learning materials and probably someone who's there to guide them.

MIKE: Absolutely. I think that everything we've talked about today is equally applicable for a kid who's got some strong natural inclination. Everything I've read about prodigies suggests that it's mostly they were just interested in it, so they practiced a lot. You don't learn things just without work. So if you find somebody who's deeply interested in something and you just give them as many resources as you can to pursue that, they can run with it.

Everything we've talked about today, providing that hook, giving people the opportunities, giving them support when they get stuck, is applicable whether somebody is mildly interested and might not really run with it very far or is full on prodigy and is going to be building the next disruptive thing before they hit 20. The same rules apply, I believe. It's an interesting thought.

It's been an interesting session. We've talked about several tools that you can use. I'd invite anybody listening to go and find some child or adult in their life who could use some help and help them out. Give them a chance to grow and find the magic that's available in programming. See you next time.

We talk about something specific here at Acima with the hope that other companies will replicate our skills clinics because it's been an extremely valuable thing that we've done.

Transcript:

MIKE: Hello and welcome to another episode of The Acima Development Podcast. I'm Mike Challis. I'm hosting today. We've got a group here that I think has been here before, so I won't start with introductions. But I'll say names as people speak so that listeners can know who they're listening to.

Today we have a topic that I'm excited about. I'm generally excited about the topics, but today is one that's kind of close to my heart, and it's what we call our Skills Clinic. Usually, we try to keep things general. Today we're going to be talking about something specifically that we do at Acima that I hope other companies will replicate this idea because I think it's been an extremely valuable thing that we've done.

Let me give some history. About, I don't know, a year and a half ago, the beginning of the summer of 2021, we hosted an internship. And one thing that we've noticed...and this applies to the internship but it also applies to a lot of other situations in which new developers come into software development. Now, there are people who come through a very traditional path into software. They go to a four-year university. They get a degree in computer science or something similar. They do an internship somewhere, and they go, and they get a job.

But there are a lot of people who don't follow that path to get into software development. And there are a lot of programs out there to try to bridge that gap. One thing that exists is software bootcamps; a lot of people have used those, which tries to very quickly get you knowledgeable in software. This applies to people who've maybe got a degree somewhere else, or have work experience or, you know, years living adulting. [laughs] So they have a good sense of how to do things in life and maybe have experience in computing but haven't learned the tools of software.

So they'll go, and they'll do a really intense bootcamp for two or four months, something like that, and then move on to getting a job, you know, an expedited path. That's a great way to get into software if it works for you. Certainly, there are going to be some things left out compared to what you get with traditional computer science.

A lot of people complain about computer science programs that they teach a lot of theory and not much practical experience. People can come out of a computer science degree and really have no idea [laughs] how to work in a real-world setting and have to learn those skills. So there are some advantages to both sides. But there are some gaps if you've gone to bootcamp so basic theory things you don't know that can sometimes hold you back.

One thing that we've done a lot is provide mentorship and internships so people internally who have not worked in software can kind of learn the ropes and move into coding and build their skills as they go. I think it's a great way to learn. A lot of people out there in the industry learn that way. And I strongly encourage it if that's something that interests you. But once again, there's often this feeling that like, oh, there are these things I didn't learn. There's not a bootcamp for people who are already working. It's something that gets you up and running but doesn't follow up after there.

People who come from a traditional computer science background as well maybe they want to learn things outside of what they learned in school or outside of what they're doing at work and build their skills. All of these people have this need to have ongoing development, ongoing learning. Oftentimes, the work environment doesn't necessarily provide that. It gives you hands-on experience but not necessarily the theory, you know, things that would build those fundamental skills. A lot of background here; I'll give one more piece of background.

When we were looking to do this internship, there was a product manager who worked with us who mentioned that his daughter was really an avid volleyball player. And during the summer, she really wanted to build her skills, and there were lots of programs around. I don't know about lots, but several programs around that will provide that opportunity, and what they call themselves is a skills clinic.

A skills clinic is not for people who've never played volleyball before. And this exists in other sports as well. It's not for somebody who's never played before. It's for somebody who knows what they're doing but wants to do drills, wants to build their fundamentals so that when they go back and play the real game, they're better at it. We said, "Well, that is the perfect name. That's the perfect name."

We need to have something like that. We need to have a skills clinic for software so that we have an opportunity to build our fundamentals to do that practice outside of our normal routine that builds the fundamental skills so that when we go back to our work, we are stronger, better, more confident, and can be better coders. So we started a program where an hour or so each day for the internship and for anybody interested...there have been a lot of junior developers, but there have also been more senior developers who've joined to get together and work on some fundamental skill, and we've called that skills clinic.

We did it during that internship and just kept it going. So for about a year and a half, we've been doing more or less daily, I'd say more, [laughs] almost always daily, a skills clinic where we get together and work on something. We started with some almost lecture-like formats where we did a presentation, talked about a computer science concept, and we've actually, by design, moved away from that. Asked for feedback and found that, yeah, that's great, but it's really hard to engage with a presentation like that.

And over time, we've moved more and more toward hands-on experience. So we're writing code, but we're writing code outside of what we'd normally do at work in a way that would teach us something new. So we have learned some basic computer science concepts and learned about how computers work, [laughs] the basics of a processor. Then I think we learned a lot more by writing some machine code [laughs] to learn how that works, not very much because that's a pain.

But then we wrote some Assembly. We looked up the specs for, you know, x86 computer and figured out the Assembly language to do a basic addition operation and then moved on. We wrote some other low-level languages. And then, we thought of low-level code in a low-level language. And then we took some time writing our own languages. We split up into several groups, and we wrote our own programming languages. I thought that was a lot of fun.

We've gone beyond that point to work on a number of different projects. And it's a great opportunity for people to get in and build their skills. It's important to me because I helped launched it, but honestly, I have not been as involved with it for a while. My role has changed somewhat. But we do have Tad on the call with us, who has really pushed it forward, as well as Ramses, who's helped a lot with that.

And they have kept this going, and they've been a great asset, I think, to the other developers and to the company. I'm curious to hear what Tad and Ramses...what do you think? I've kind of talked about how we launched it. I'm curious what you've been doing for the last several months as well as your thoughts about the value of skills clinic.

TAD: Well, what we've been working on primarily is a chatbot for our company's Slack channel. The interesting thing is that we kind of just do whatever people need to be done. We have a default project that we work on every day. But there have been a few times we just barely finished our internship program for the summer, but I've just talked to the interns and been like, "Hey, what do you need? Like, what holes do you have? What are you missing?"

And some of the days we just talk to the interns and let's say like I don't get this CSS thing, or I don't get this JavaScript thing, or I don't get this, whatever. And it's just kind of an open forum for people to come in and say, "I'm curious about this," or "I feel like I have this kind of hole in my knowledge," or things like that. And we'll fill those in. But it's been really nice to just have a default project that we work on every day.

The project that I mentioned, the chatbot, has been really interesting. I chose the project because I wanted to do something that had a really good feedback loop, meaning you can write some code and get an immediate response and some satisfaction from what you're doing. And chatbots are kind of like that where you can write...in our chatbot framework, they're called handlers where they just handle...you say if you see this certain string or if you match this regular expression, then do something with it. And so to be able to, in 10 minutes, write a handler that can return a dad joke when you ask for a dad joke, or something like that has been really interesting.

We do primarily Rails development. And so I chose a project that wasn't Rails just because Rails does a lot of things for you and has a lot of opinions. And so I wanted to choose a project that we could kind of build-up from scratch and make decisions as we went and get into the nuts and bolts of things without that kind of Rails [laughs] paradigms and Rails convention and everything kind of hanging over us. So it's been really interesting. We've encountered tons of little things that I don't think you would encounter working on a Rails project but are very common problems that developers have to wrestle with, just generally speaking. So it's just been really interesting.

MIKE: I think you said a couple of things that I noticed when working on this that are important for keeping a program like this going in the long term. You said you have a long-term project that provides opportunities for learning.

TAD: Yeah.

MIKE: I found that getting things started as well to be exceptionally valuable. At first, I was preparing a presentation every day, which was fine. And I guess you could do that if you had time. But that wasn't as engaging. [laughs] When people had an interesting project to come back to, it kept that continuity. And it's not that we would do that every day, but that continuity was really helpful to allow people to continue. And if you have an off day where you didn't have time to prepare, well, that's great; people can pick up where they left off.

TAD: Yeah, I started out the same as you when I was doing the skills clinic, where I was constantly trying to figure out material to present. And it was taking a lot of research, and I was going back through old college notes and stuff. And like, oh man, what are all the things that I could teach these folks? You touched on it where it's like, okay when you come through a bootcamp, you get a lot of experience, but it's very narrow and how do you broaden that out?

And so it's like, okay, well, what are all these topics that I can do to broaden out their understanding into all these things? And it turns out that just working on a project that is not the same as what you're doing in your regular day-to-day work was just, well, I don't know if it's serendipity. It's just surprising how many common developer problems and patterns came out of just working on a project together.

And I didn't have to sit and research all these things. It's just like, oh, yeah, we've hit a snag, or we've hit an issue. How do we solve it? Oh, you know, there are already patterns or solutions out there. Let's talk about it and figure out which one works for us. And that has been really surprising to me almost.

MIKE: I've had a similar experience that you actually get your hands on the keyboard...this applies beyond software, you know, we talked about this skills clinic. When you go out into the real world and do real things rather than just talking about them, it's remarkable how much you notice that you don't notice when you're just trying to explain to somebody.

You notice this a lot when onboarding somebody who's just started somewhere that, oh yeah, you do this to set up. Oh wait, and then there's this other thing. Oh yeah, then there's this other thing you've got to do. Oh yeah, you have to install this. And oh yeah, well, you have to download this. You know, all of these things start coming to mind and becoming apparent that you just gloss over in your mind when you've done it a thousand times. That hands-on work surfaces those learning opportunities that you wouldn't get otherwise.

TAD: Well, I'm curious because we have several people that also participate in the skills clinic; just throwing it out as a question to the rest of you here. What are some of the things that you've learned from skills clinic that you don't get from regular work?

JASON: Right out of the gate, the first thing that came to mind is direct interaction with Redis constantly. And working in a Rails project we just take for granted a gem like ActiveModel and ActiveRecord and how those work together to give you this seamless interface where suddenly you don't have that...you don't even have a database anymore to enforce cardinality. And you're suddenly trying to figure out, okay, how can we implement a model where I just want to implement some sort of find by functionality where I want to find a record of some model by an attribute?

We're getting an introduction to lookup tables. And, again, it's a basic idea, and I think everybody's aware of it. But it's like so infrequently...I've never had to implement a lookup table. And we got to do that together as a group. Tad kind of walked us through the basics of that. So some of the most basic things that are provided to you and you take for granted you have to surrender to that and implement basic functionality so that you can proceed with the project. So that was the first thing that came to mind, no database, having to interact with Redis, and doing everything from memory.

TAD: Yeah, just to give a little context, we're using a gem called Lita, L-I-T-A that was just barely recently abandoned [laughs] but we worked with it, and we're still going with it. And it doesn't have anything behind it except for Redis is kind of the brains or the storage for the bot. And to have something that's primitive is a really interesting constraint.

Because, like Jason said, you don't have indexes. You don't have joins. You don't have a lot of the things that a traditional database will give you. So it's like, I can put data in; I can pull data out. How do we solve these problems? It was a really interesting...just out of curiosity, how familiar are you guys with Redis now as compared to a year ago? Is that something you felt like you've learned a bunch about?

RAMSES: Yeah, quite a bit.

JASON: Yeah, quite a bit more. I'm comfortable with the different primitive data types that Redis supports. But not only that, but a recent problem we ran into was a timeout issue where we would have, you know, we'd ask our chatbot to do something, and in a development environment, it works great. And it would perform its task. It was the expected output. And then we tried doing the same thing from Slack, and it would do the same thing like ten times in a row. And it just kept repeating itself over and over and performing the same task with no obvious reasons as to why.

And I think the problem was that there was a timeout. So Slack was expecting a response or acknowledgment within a certain amount of time. Our main thread was busy, and wasn't able to respond. So we realized, okay, we've got to offload this task and perform it asynchronously. Long story short, we did say, hey, what library exists out there that does thread management better than we could write it and handling locks better than we could do it? Let's implement Sidekiq. So we go and implement Sidekiq.

And there's a configuration problem where, you know, we need an instance of the robot itself that Sidekiq would need to be able to complete the job, so one rolling problem into the next leads to these different design patterns. And long story short, being able to interact with Redis directly where we're able to basically...we don't need to pass an entire configuration to Sidekiq now. We can have a Sidekiq worker write essentially to a response queue. And we can have another loop that is always checking that queue and can read things back. So without being able to interface directly with it, that solution wouldn't have been as obvious. That wouldn't have been a more or less trivial thing we completed in one skills clinic session.

TAD: Yeah, that was really interesting. To give our listeners (I don't know how many listeners we have, maybe just one.) some context, so Slack gives you a WebSocket. So they've got a new API where you basically send some information to Slack and say, "Hey, I would like to connect." And they give you a URL for a WebSocket. And then you connect to that WebSocket and you send a message, hey, I'm here. I'm connecting to this WebSocket. And then you tell your app in Slack (There's a little checkbox list.) all the events you want it to tell you about that are happening in all the channels.

And for all those events that you signed up for, it will send you a chunk of JSON down this WebSocket as one of their event structures. They send you an event, and we had our bot grab that event, parse it, pass it along to all the handlers, and then do a response. We also have to give an acknowledgment back to Slack, like, yes, I got this message, or else Slack is like, oh, you didn't acknowledge the message. I'm going to resend it; I'm going to resend it, I'm going to resend it. And it's going to keep resending it until it sees an acknowledgment.

Well, if you get a message, yes, you can acknowledge it. But then, if you go and do a bunch of work that takes a while, then the next message that comes through, you are still busy doing work, and you won't be able to send that acknowledgment back. And Slack will start doing all these retries on you. And so we realized, okay, we've got this loop that is just checking for events. If we block that event loop, we're going to have to figure out...either store up all these messages or do something because Slack is going to start sending us a whole bunch of retries, and we don't want to do that.

We want to have that event loop looping as fast as we can. And the solution, like Jason said, is let's offload the long-running processes to Sidekiq. And I was actually really thrilled by this because having an event loop and being careful not to block your event loop or [laughs] slow things down in your event loop is actually a fairly common problem. Even on your phone, if you tap a button and if you don't get a response right away, if it doesn't do something right away, then you think it's frozen up. You're like, oh no, I locked up my app.

So responsiveness and making sure that you respond and handle those things right away is really important. But I don't think anyone had ever encountered that kind of a problem in day-to-day work. So I'm like, oh man, yeah, like, making sure your event loop is fast and responsive is a really cool problem to solve. And so I was kind of thrilled that we hit that because then we could talk through it and talk through some different solutions to fixing it.

MIKE: That's really cool. Event loops they're everywhere, right?

TAD: Yeah.

MIKE: JavaScript has taken over the world. In JavaScript, the world revolves around that event loop. [laughs] That's kind of a big deal.

TAD: What else have we done? I'm trying to figure out what are just some of the challenges we've had lately. Oh, one thing I'd be curious to have you guys talk about is your scheduling algorithms that you guys worked out. So a little context before I throw this out is one of the handlers we want to have this bot do is figure out pull requests assignments. So we want to be able to say to the bot, "Hey, I've got this PR that I've just finished. I need reviewers for it. Will you assign some reviewers to it in a fair way?" And it will look through the reviewers.

And someone like me can say, like, "Oh, I'm going on vacation. Hey, bot, don't assign me any PRs for a while." And then when I get back from vacation, I'm like, "Okay, bot, I'm ready to accept PRs again." Things like that. So I'd be curious for you guys to talk about how you figured out that problem.

JASON: Part of the problem with the PR assignments is we have a concept of full reviews and code reviews. So when we get work per project coming through, full reviews typically take a long time. There's a lot of manual testing. You want to make sure that a feature that it could be [inaudible 20:53]. Whereas in code review, you don't need to do manual testing, but your primary focus is on code. Typically, a full review also includes a code review, so it's just more work. And we try to rotate or make those fair.

And right now, it's a random approach. Over time, it tends to even out, but there actually was an issue with our bot assignment basically that we have integrated with GitHub where it wasn't being fair because...it had to do with alphabetical name sorting. So some people, like another developer, we had Steve where we actually have an Easter egg for him in the codebase with a flag [crosstalk 21:31] where that would indicate, okay, we're only going to be assigning code reviews. So if you pass on that flag, we're just going to do code reviews because Steve had discovered this kind of unfair assignment.

So anyway, we decided that there was a lot of work that was done considering how are we going to do this? How are we going to keep it most fair? But in the long run, we have two queues. And we basically came to an approach where we're rotating people through the queues. And we're always checking to make sure that we have the most recent updated list of team members for the given team that were performing an assignment. So that's part of the command we can pass as the team. We update that.

If we have people in the queue that are no longer on that team after the most recent call, we have to remove them from the queue and redistribute that queue in a fair way. And when people are unavailable, that's another thing. You know, we could have people on the team, like you said, Tad, that "I'm going on vacation. Please don't assign me any." You can tell Robbie to make you unavailable, and we'll account for that as well. We have to make sure that it's fair. And then, when you come back, what's the fairest approach to getting full review assignments again or code review assignments. So there are different options and flags that you can pass through.

But queue management has been a big topic that has required a lot of thoughtful consideration and considering different approaches to that. Ultimately, we have a kind of first-in, first-out approach. So it's a general queue structure for these lines, but it's a rotating queue. So anyway, I don't want to get...I feel like it'd be really boring talking about the individual queue structure unless you want to talk about it.

But there's a lot of iteration and a lot of discussion. We probably took probably almost six or seven skills clinic sessions just developing a fair queue structure and then, with every action that you take, making sure that we maintain the fairest approach for those PR assignments. As an aside, from just the queue structure, the cool feature about the PRs and the handler is we've created an API client with GitHub that has all this base functionality built out.

So it's a simple, almost trivial way of once we do that PR assignment, we update the actual description on the PR itself. So the developer doesn't need to add those people. It adds the people to the assignment then adds him in the description with an @ mention. And then, in the Slack channel, we'll use their Slack @ mention name to call their attention to the PR they were just assigned to. So kind of as an aside, and I feel like I'm very long-winded with this, but the queue structure itself that's a problem that I don't think we would have encountered in our core work. It took a lot of thought.

TAD: To me...I didn't work on that directly. Sometimes in the skills clinic, we kind of break into teams and work on our individual parts. For me, one of the more fascinating things was when I learned about queues, it was in a college setting in a class. And they just said, "Here's a data structure. Call the queue. Here's your homework assignment, implement a queue, and implement a queue using a linked list and implement a queue using an array. You'll be graded on it on Friday."

And so we got queue theory, and we got a queue assignment, but we didn't have any use for it. We just kind of did one, and then we were done. And we moved on to the next data structure. And yours was really interesting to me because it came about organically because you were talking about, okay, how do we distribute this? How do we make it fair? How do we do these different things? And it's just like, so we have code reviews, and we have full reviews. What if we had essentially two lines that people were standing in and waiting to be up for these things? And that kind of just matches a queue perfectly. And we've just implemented queues in Redis, and that worked.

The other thing that was really fascinating to me is scheduling problems are, I think, a pretty common problem to encounter just as a developer in general. And to see you guys working through the scheduling problems making sure that, you know, because I learned these things in a formal classroom, and so we learned terms like starvation. Like, what if this job never takes place on accident, or what about all these different things?

And you guys didn't necessarily have that same vocabulary, but you guys encountered the same problem. And you found solutions for the same kind of problems as you would in just regular scheduling. And I thought that was really interesting to just see that just having a real-world project introduced all these concepts to you just organically, and you had to just solve them and work through them just organically. So that was a really interesting thing for me to observe just from the outside.

MIKE: Such great stuff. I'm curious; we have Mark with us, who was part of our inaugural cohort, to say it in [laughs] fancy words. He was part of our first group in an internship that did the skills clinic, and then he's come back. And he's done it more recently. I'm curious, Mark, what parts of the skills clinic have you found most useful that you would recommend other companies implement in order to help people who are wanting to grow their skills, from your perspective at least?

MARK: Hello, I'm Mark. I guess the part that I find most useful is the explanations that my teammates give when they're editing the code right in front of me because they can explain what they're doing, as well as explaining how they've come to this conclusion, as well as other things like explaining how to debug something. Because you can tell someone to debug something and give them tools but giving someone tools to debug something and actually showing them how to debug something and what to look for when debugging something are very different.

TAD: Something that's been funny to me is we usually do a shared session using VS Code, which I think is crazy. Like, I love it that everyone can code and type and talk to each other at the same time. And one person could be working at the top of the file, and the other person can be working at the bottom of the file. But that's just an aside.

What's been really interesting to me is I'll present something, and I'll talk about it, and I'll just be doing my regular thing. And I'll be like, oh man, I need to debug something, or I need to do something. And afterwards, people will tell me, "Oh, I totally learned some little debugging technique," or "I learned some programming technique just by watching you." And it wasn't necessarily even related to what I was talking about. But people afterwards will be like, "Oh yeah, I didn't know Pry could do that." Pry is like a Ruby REPL that has a lot of cool stuff built in. And I'm like, oh yeah, well, I use that every day.

But it's interesting to see just working together with people, with other developers, and you can just pick up on the little things that they do to make their life easier, or make their debugging faster, or something like that. And you could just be like, oh, wow, that's really cool. I'm going to squirrel that away, or I'm going to put that in my toolbox too. That's been really interesting to me.

MIKE: Well, that's interesting. So you're saying that oftentimes, the most valuable...and this seems to be a recurring theme as we've talked about this. Oftentimes, the most valuable opportunities come unexpectedly; you've mentioned serendipity. You're working on a problem, and this side thing comes up, and everybody learns way more from that side opportunity [laughs] than what you had planned initially. You're exploring around, and you find these gems that you wouldn't find if you were just focused on going to your original destination.

TAD: Yeah. And just seeing all the different approaches that people are taking to something has really helped me broaden my thinking about certain stuff that I've been doing as well, which was kind of like a side effect that I didn't expect.

I'm probably one of the more senior people on the team, and I expected it to be kind of like I'm teaching them. But I am surprised at how many little things I learn or understand better just based on what they're doing, or their conversations, or their questions. I'm like, oh wow, I kind of expected it to be kind of single-directional. But we're all working together and teaching each other simultaneously, which has been really fun for me.

JASON: Adding to that, it's one of those environments where I don't think anybody hesitates to ask a question or even to casually [laughs] just be honest and say, "I get that you guys get all of what's going on right now. But I looked up at my screen for 20 seconds to answer a question, and I have no clue what's going on." And everybody having that kind of friendly almost, you know, just pure vibe. We're all working on the same problem. We're all trying to achieve the same objective.

And there's absolutely no problem with someone saying, "I do not understand what you're talking about. Please teach me." That's the entire idea of the skills clinic. And so knowing that that's the entire idea, I don't think anyone's afraid of speaking up and saying, "I don't understand something." And it's led everybody to get a lot closer.

One of the awesome side effects that I've encountered is just another...and this has come up in previous podcasts, but just that getting-to-know-you sort of thing. It's just another avenue where those social interactions are so important because you can't learn from other people if you don't talk to them. [laughs] And you don't talk to them if you don't feel comfortable talking to them. So I often ask everyone pretty much on the call for help independently off-screen people who have been in the skills clinic.

TAD: Yeah, I really like here at Acima; we talk a lot about psychological safety. And I think we even turn that up in skills clinic where we all come in, and we're just like, the whole reason we're here is because we're ignorant about something, and we want to learn more about everything. So there's no shaming. There's no like, "Oh my gosh, you didn't know that?" nothing like that. It's really exciting to say, "Oh, you didn't know about that? Well, this is exciting because today is the day you get to learn about..." and then, you know, something.

We're excited to share with each other as opposed to putting each other down or, I don't know. I'm curious to ask, maybe Eddy, what have you learned from skills clinic, or what things have you gotten out of it? And I'm asking you because you're someone who's in our QA department who knows somewhat about programming but doesn't have any formal programming experience.

EDDY: What I find valuable is how someone uses their resources to find a solution to a problem. It's really easy to get assigned a pull request, but you never really get to see the cycle of what it went through in the back end to get that successful outcome. So I think it's been really integral and critical for me to...or more valuable rather to see the different approaches for individual problems and how they're unique and how we can use you as a resource or the Atlas mentoring channel, or Stack Overflow and such. So to me, that has been super valuable to see how everyone's approach is different.

TAD: Yeah, that's interesting. Something that I've noticed is that it's not lack of skill; it's lack of experience, probably, that slows people down or blocks people. So when I say that, for example, I've talked to you and maybe some of the other people coming in. And if you're new coming in and you don't really have context or experience, so a lot of times you're just like, I don't know, Google, and then, I don't know, Google again. I don't know, Stack Overflow.

And that could take you like an hour before you get to the answer or figure out what you need to do. But if someone else who's familiar with it comes along and is like, "Oh yeah, I know exactly the documentation that you probably want to read," Or "I know exactly which library you could use to fix that or solve that problem," then suddenly, it's like, oh, [laughs] blindly searching for an hour just got replaced with 10 minutes of talking to somebody and getting a recommendation.

EDDY: I just wanted to kind of echo what you said. I think it's...I saw a video from what makes someone successful. And one of those topics was, like, reach out to someone who's in that same profession, who's been there longer. It's like a cheat code, like a shortcut. It's like, you can eventually stumble through that same problem through sweat, and agony, and blood, you know, and stress, or you can reach out to someone who's already been through that map, you know, and cut it significantly to get the answer. So why wouldn't you use someone who has run into that problem? It's like a real-life cheat code, you know.

JASON: [inaudible 35:13] was a senior developer at Acima for a long time. And I had a conversation with him once, and he oversimplified it, or he may have been facetious, but I think there's a kernel of truth in this. He said the only difference between a junior dev and a senior is how proficient they are at finding the answers that they're looking for. They learn to learn better, or they learn to find those answers or search better. There could be a number of different things, but that just came to mind as we were talking about this.

MIKE: More than a kernel of truth. It's remarkable how true that is.

TAD: Well, that's funny because what was it? Like a couple of weeks ago, you were implementing some JavaScript stuff and some marketing and tracking and things like that. And you reached out to me, and I was like, "Oh my gosh, Jason, I've got scar tissue. I've got stories. [laughs] I see you're about to step on a path that I've been down. And let me tell you, it's not pretty at the other end, but here's how it will go. And here's how you're going to get there."

That was just kind of funny to me is that I think we all have scar tissue from some gnarly problems we've had to deal with and a story to tell, and then just like, oh yeah, I see what path you're on. [laughs] Here you go, like, good luck. And here's where you're going to end up.

JASON: Exactly as it was mentioned. It's kind of funny. What you were saying and what you were explaining to me about the problem we were encountering is exactly what was happening. And it sounds like it's just something everybody has to deal with.

MIKE: We've talked about the origin of this skills clinic idea, a lot of things we've worked on, and what has made it useful. And it sounds like, if I were to summarize what I've heard, a lot of what has made it useful is not necessarily the overt this is what we plan to talk about, but the incidental benefits of having developers work together and watch each other and learn. Of course, you can get that from pairing. There are other scenarios that that come up.

But in skills clinic, you're actively going and looking for these new experiences that you might not encounter otherwise. From my perception, I think it's been a very valuable thing that we've done, and I would recommend that others try it. Is that a universal sentiment? Would you recommend that other companies try this idea, start up a skills clinic, you know, and start this daily pattern to improve your skills together?

TAD: Absolutely. I've learned a ton. And I've hit things that I didn't expect to hit and learned things I didn't expect to learn. And like I mentioned earlier, I kind of expected it to be me teaching them, and it's us teaching us, which was awesome.

EDDY: I wanted to say as someone who has a year under their belt as far as learning how to code, it was incremental learning until skills clinic, in which case I feel like my skill has grown exponentially, so yes.

JASON: For those concerned that it's a wasted hour every day, [laughs] you get 100 fold back out of that invested hour. It's amazing how much you can get back. Like Tad was saying, it's serendipitous that you talked about this topic incidentally on Tuesday, and Thursday, that solution came up in my actual work. And that just saved me more than the hour I invested in skills clinic. So it's this compounding effect.

MARK: I think skills clinic is very useful, at least as a coder. For other jobs, they might not do it as often or might structure it differently. But I do think implementing some sort of skill clinic session placed once a week would be good for other companies as well.

TAD: I really like the regularity that we've set up that now I know every day at 10:00 o'clock I'm going to be doing this. I think when we had alternating mornings and afternoons and only some of the days and stuff like that, we kind of lost something. But having it as a regular part of our day and having it as something to look forward to and having it blocked out so we're not having meetings on top of it and stuff like that has really made it much better.

MIKE: And maybe that's a good place to land is that if you want to make this work, you got to be consistent. You should come up with something that you can work on for a while, something out of band that you're not necessarily working on in your daily work to give people different experiences. And just be consistent about it. And we've heard some witness testimonials that it's an investment that has a high return.

Those who are listening who are in a position to try something like this, I highly recommend that you try it. And the worst thing that happens is it doesn't work out for you. But this opportunity to improve the skills of the people you work with and help everybody build them as they have and grow them and become more effective is extremely worthwhile. Thank you, everybody, for being here. Thank you to our listeners. I hope you can put this into practice. See you next time.

Have you been through a global pandemic recently? This episode is for you. Today we're going to talk about fitting remote developers into a team.

Transcript:

DAVID: Hello and good morning. Welcome to The Acima Development Podcast. Today we're going to talk about fitting remote developers into a team. And if you have not recently lived through a global pandemic, you don't need to hear anything that we have to say, so more power to you.

Today we're going to talk with...I'm just going to read through the panel, and then people can speak up and shut up as they go through. But we've got Mike Challis. We've got Kyle Archer. We've got Jason Loutensock. We've got Ramses Bateman. We've got Eddy Lopez and Mark...oh, Mark, I'm going to mess up your last name, Kendzior?

MARK: Pretty close, Kendzior.

DAVID: All right. So remote development, what do you think?

MIKE: This one is interesting to me. I have been doing remote development most of my career. At first, it was almost an accident. My wife was gravely ill while pregnant, and I wanted to be close to her. So I tried to be home as much as I could. But I was mostly working in the office at the time, like work through lunch and get home as soon as I could.

And after my son was born, I tried to be there to do what I could as much as I could. And around the same time, the company I was working at went through some change of management. And basically, nobody that I had been working with closely previously was there anymore, so I just worked in the office less and less until I just wasn't working there anymore. And I've never really gone back.

So I've been working remotely for a long time. And so I was well-positioned for this pandemic because I was used to it more than a lot of people were. I know that, for me, being remote has a lot of obligations on the developer that is remote that you don't have as much when you're in the office. You might want me to say, oh yeah, well, there are all these things that the office needs to do to support the remote people, and that's probably a lot of what we'll talk about. And I think the opposite is very much true.

If you're remote, there are certain things that you just have to do. You have to actively be more present in ways than if you were in person because you lose all of those visual and social cues that you would have otherwise. If you're on, let's say, Slack, you need to really be available there, make sure that you're around, and you respond quickly. And then, if you're in a meeting, you maybe speak up more than you would normally do to kind of push against your instinct to sit in the back of the class.

Because if you don't push against those sorts of things, then you tend to disappear, not just to the others but even to yourself. You lose some of that social engagement. As a remote developer, the things that have been most important to me are being really proactive in that way and really making sure that I am present. And I feel like that has helped quite a bit for myself.

DAVID: That is awesome. I think it's interesting that you've had kind of the opposite conversation as me. The last few times that I've done the how to fit remote devs into a team, I've come from the thing that you've just described. Like, all the previous conversations I've had have been in the context of the company kind of doesn't like remote work, so they're not going to give you an inch. It's up to you to make it work and convince the team in the company that it works. So, yeah, the last few times that I've been on this topic on a call, it is entirely been how can you fit yourself into a team when you're remote?

And 100%, there are things that casually happen at the office that have to be explicit, and I'm going to use the word premeditated because it sounds a little bit sinister. And it certainly is conscious and a deliberate thing. There are things that, if you don't pay attention to them, they will run away from you. There are things that happen at the water cooler that nobody at the water cooler thinks is part of the regular workday.

But if you're not part of it and you find out everyone is in on this story or this joke or has heard about the upgrade that IT did to the network entirely at the water cooler [laughs], and you're the only one who can't get on the network, right? If you don't consciously and deliberately inject yourself into certain conversations, those conversations will just quietly happen far away from you, and you'll get cut off out of that information.

So I'm kind of excited to explore both sides of this, like, what can we do to be better into it as when we're remote. But also, are there some things that we can say, okay, company, we're remote now. We really need you to start doing this or stop doing that.

MIKE: I think that's where we're thinking would be the biggest focus today. I don't know; we can talk about whatever you want; it's our podcast. [laughs] We conceived this idea from the company side. I think that there are some...I've read some things that other companies have said about this. And I've watched what people have done, and there are definitely some things that a company can do. And the pandemic has definitely pushed remote work forward, particularly in tech, where you've got a job that a lot of people can do remotely.

I haven't looked at statistics in the last few months, but last I looked at them, a majority of people in our industry were at least somewhat remote, and that's a major change. And the companies that are not accommodating then they're losing the opportunity to have people contribute that would otherwise not just losing employees but losing a portion of the employee that they have working with them. And that's unfortunate for everyone. I've got some thoughts as to some vital things that a company should do. But I've been talking some, so I'll be quiet for a moment and see if anybody else wants to pipe in here before I say anything.

JASON: I don't really have any thoughts about what the company should be doing but kind of just off-the-cuff thoughts. I find myself actually working more and maybe even feeling a little bit more anxiety about needing to be present, kind of touching on what Mike was saying how you have to be present. You have to keep your eyes on all the different channels. And recently, when I've had to go into the office, I've found it majorly distracting.

And there's a lot to be said for social interaction that's wonderful and great for your mental health, but I've just found it's really hard to get work done because all of your co-workers want to come and say, "Hi. I haven't seen you in a while." Or otherwise, maybe you see them every day, and they just want to chitchat. I just find, in general, especially with a development-type of job, I need my focus on what I'm trying to do.

It's kind of funny; I found myself working more and checking my phone even more, and being concerned about our team's projects even more simply because I'm there. I always have access. I don't have an excuse for not trying to pitch in and look.

MIKE: I relate to all of that, [laughs] which is a topic for another podcast. But maintaining boundaries [laughs] is something that we should talk about sometime. You have to say, "You know what? It's the end of my day. I need to sign off, even if that means absolutely nothing." If you're still sitting on the same couch or generally going to the office, you got to say, "Okay, now I'm putting down my laptop, and I'm going to go do something else," because otherwise, it will just consume all of your time.

DAVID: There's a really good concept that I learned years and years and years ago that was based on something a doctor told me. There was a problem with my health that was being...and I don't want to get into too much details. But what was happening is I was pushing too hard into one direction, and that was sort of setting a pendulum effect where I would swing back to the other side, and I would crash to the other side of the pendulum. So you can imagine not getting enough sleep, like staying up all night to push on a deadline, and then you swing back the next day, this pendulum effect.

The pendulum itself isn't bad. In fact, there are certain things where you need that pendulum effect. I realize this is an obscure, abstract metaphor. I'm going to make it concrete here in a sec. There are times when the pendulum can get stilled, and that's just as bad as having it swinging out of control. And for remote development, this notion that I can get up, I can take 17 steps from my bedroom to my office; I can put my butt in a seat, and I cannot move for 16 hours straight really stills a pendulum.

And one of the ways to force that pendulum to pick up and swing again is to have a schedule to say I'm going to get to work at 8:00. I'm going to quit work at 5:00. I mean, you don't have to be rigid about it, but having a set thing of, like, I'm going to get up, and I'm going to get this done before work o'clock starts. And I'm going to do this after work. And I am; I'm going to log out.

There's a separate idea I have about being available versus being present in terms of being available on Slack and that sort of thing. But for me, my days just turned into this bland gray smear just one day after, and the days blurred together because I would work through the weekends. And there was no punctuation to my life. It was just get up, work, sleep, get up, work, sleep, get up, work, sleep.

And then all of a sudden, I was 38, and I was like, where did my 30s go? And it was all just one big blur. And it wasn't until somebody said, You have to push yourself." I could have said this all very, very succinctly. If you want to sleep better at night, go exercise during the day. Swing that pendulum, push it hard in the opposite direction, and you can make it swing back on you in the other way.

MIKE: So much truth there and even just that last piece. I don't sleep well unless I exercise during the day. [laughs] That's a very real aspect of my life and that schedule as well. I try to get some exercise in before work. As I mentioned before we started recording, I went out and mowed the lawn this morning.

It sounds like you thought, oh boy, that sounds awful, but that means I have sleep tonight, and [laughs] not only that, but I'm much clearer headed in the day if I get some exercise in the morning. If I do something that's not work in the period before work...and I do, I usually get up pretty early and get a lot in before my workday starts. And I feel like that makes me more effective working on this.

EDDY: Mike, that's funny. I mowed my lawn earlier this week. And there was something fulfilling about putting all that cut grass in the garbage, and you're like, yeah.

MIKE: [laughs] Yeah, change your pace. I know a lot of developers who are musicians, a lot of them who are gardeners. They have a hobby that's very different than software development. And I think they're kind of mutually reinforcing I need to switch that pendulum to the other side to let it swing and do something else. It's refreshing to your mind. Switching to one side and then the other allows you to go back with a cleaner head than if you just, I don't know, watch Netflix.

DAVID: A slightly related tangent to that is I have found that if I can't get my head unfoggy, getting up and walking away from the desk for 10 minutes, just walk out the front door and just start walking, getting some sunlight and some fresh air and getting your quadriceps moving, largest muscle mass on the body, getting the tiniest hint of cardiovascular can really jumpstart your brain. So whenever I need about ten more IQ points to bring to a problem, I will get up and go for a walk. It's that contrast of activities that really, really helps.

EDDY: And I am curious, though, coming from someone...myself, right? This job is their first experience in the remote work area. I wonder if other people experience this phenomenon to where I found that it took some discipline at first to keep myself accountable while getting my job done because suddenly, I had the liberty to get up whenever I wanted to go to the bathroom or pick up my phone suddenly because someone sent me a message. And before I knew it, I was going through YouTube videos or a Twitter feed. Also, I tend to forget to eat. So I found myself setting a reminder to, like, hey, get some food, you dummy. I'm curious if people can relate to that.

DAVID: I think you just revealed both sides of that sword. It's like, sometimes, I get distracted, and I look at things that I shouldn't. And other times, I forget to eat. You have just revealed both sides of that sword, right? Your attention is going somewhere that you don't want it to go. But in both directions, there are times when you need to be taking care of yourself, and you don't because you blur over into work, and that, again, it gets into boundaries and into sharpness. And you not only have to be disciplined to focus on your work, but you have to be disciplined to focus on yourself when it's appropriate.

MIKE: I have the same responsibilities that it's like, you got both sides there, [laughs] and they're related. I tend to struggle more with the forget to eat side or working too late, or checking the phone at all hours. I think, oh, okay, I got to take care of this problem. It's still on my mind. And almost reflexively, I'm checking and keeping my mind on that, which doesn't give the mind a chance to rest.

But that's really not much different than getting focused on something that's not work and letting the work slide. Both of them are about a lack of boundaries. You're cutting off your freedom a bit when you set up a schedule, like, hey, I want to be able to do whatever I want. If I have a schedule, well, that makes me work for the man, right? That's really not how it ends up working. When you set that schedule, well, you're the one who set the schedule.

DAVID: Mm-hmm. You're the man. [laughs]

MIKE: Exactly. You're the man or the woman. You make yourself in charge, and you're the one setting those guidelines. You're still in charge. You're just doing it consciously rather than by the seat of your pants. And if you do it consciously, you're probably going to do a better job like saying, "This is the choice I want to make, so I'm going to make it." When you make that choice with foresight and thought, you're probably going to do pretty decently and set yourself up well.

If you let it slide a little bit around the edges because, you know, I feel like sleeping an extra five minutes a day or whatever it is, fine. But having those guidelines that you set for yourself is empowering. It isn't somebody taking something away from you. It's you giving yourself your best efforts at time management when you are conscious about it. And it works out. Yeah, I'd strongly encourage anybody who's doing remote work to create a schedule that they'd like to have and then follow it because it's surprisingly liberating.

DAVID: That is amazing. I just had an epiphany as you were saying that. I find it endlessly fascinating that you take an office job where you are required to go to a certain place, and you're required to sit in a cubicle or in an office. You're required to get work done from this time to this time and then take a break at this time and then work from this time to this time. And we give that back to you when you're remote.

You can fudge when you show up to work. You can decide where you want to sit. You can decide how you want to work. You can decide how you allocate. You have ownership over all of these details of your job. And the first thing you lose is yourself. Isn't that interesting? All of a sudden, I'm in my office doing my work on my time, and I lose myself. That blows my mind a little tiny bit.

MIKE: Yeah, it's a big discussion about freedom and what that consists of. So there is a metaphor I like to think about regarding this idea, which is semiconductor manufacturing. So the current generation of chips that they make of processors, what are they? Under three nanometers nowadays? Something unbelievably small. And if you ever see any video of those facilities where they make those chips, it's crazy. Everyone is walking around in what looks like hazmat suits, the bunny suits they have to wear, so they don't get any particles off their bodies anywhere in the building.

They'll have a building the size of a big-box store or bigger. It's all laminar flow, like, you've got fans in the floor and the ceiling that keep all the air moving vertically rather than horizontally, so no dust moves from side to side. And they get exceptionally pure crystals of exactly the right chemical makeup and slice them into these incredibly thin wafers. And then, they go through an amazingly precise photographic process to etch channels in them.

And here's just where I'm going with all this, the level of precision that is required to make those chips is mind-boggling. And the billions of dollars in investment to build the facilities to get to that degree of precision is mind-boggling. Sometimes we perceive freedom as being able to do whatever we want, and I'm thinking here in the context of remote work. Hey, I'm remote. I can make whatever schedule I want. I can do whatever I want.

And we think, oh, whatever we want means whatever our whims are at the moment. There is a kind of freedom that says I can do what I feel like in the moment. But the freedom that we have to do things because of those semiconductors is phenomenal. I can carry better than the Library of Alexandria in my pocket all the time. I can search all of the world's knowledge and get back results in less than a second. I can look at cat videos.

There's just this vast quantity of things, a pool of information that's available to me, not because people did whatever they felt like in the moment but because people abstained, right? Found the very exact set of steps to follow and followed it. And that precision, that resistance to moving away from the exact set of instructions, actually was incredibly empowering for the companies that make the chips but also for everybody else.

Technology is not based on doing what we want in the moment but on precision and following a very precise set of instructions. Thinking about freedom in that sense, in terms of empowerment, empowerment doesn't come from following the whims of the moment but by hard work and precision. And in that definition of freedom, you gain power. You gain the ability to do, not by removing constraints but by adding them, the very specific constraints that you have chosen.

DAVID: I just closed another loop in my brain here as well that, ostensibly, the topic that we were going to talk about today...and I love it when the podcast goes slightly in a different tangent. But we had started off talking about what can companies do to help fit remote devs into a team better? And I realized that we've actually circled back around to that very answer, which is the big resistance to remote work 5-10 years ago was, well, you might just go home and sit on your thumbs and do nothing, and we have no way to watch you and that kind of thing, the whole Overwatch Overlord kind of thing, which isn't great.

But when you're remote, I definitely feel this pressure to...I got to get stuff done; I got to get stuff done; I got to get stuff done. And every time I think about my output at work, I think about it in a very static way of like, oh, I only moved two tickets today, or I only moved this much work, or I only did this much work. And so anytime I think about what do I need to do at work when I'm at home, it is, oh, I got to do work which, again, is a very low contrast kind of idea. It's just, oh, just push on this.

If I take the time to step away from the computer, get some contrast, go for a walk, get some oxygen, do these things that I don't like doing...I'm not an exercise-loving person. I'm wildly sedentary. What can an employer do to help fit remote devs? I think it might be to remind and encourage those remote devs to get some contrast in your life. Maybe the best thing you can do to move this project forward is log out and go to bed. Get your head down; get eight hours of sleep under your pillow.

Step away from the computer. Go for a walk, go eat lunch, go out to lunch. Get away from your house and go out to lunch. Rather than just sitting down and saying, "Well, the Jira burndown chart shows that you've only moved 17 points of velocity in the last two sprints," or whatever. Instead of just making everything homogenous and uniform, encourage contrast, both in and out of work.

MIKE: I like your references to the contrast. Keep your life colorful. That seems like good advice, not just remote work but in general. [laughs] It sounds like the kind of job you'd want to have, colorful rather than dull.

DAVID: And maybe that's not for everybody. My wife and I have wildly different personalities that complement each other very well. She kind of keeps me anchored, and steady, and stable. And I'm the creative, flighty, occasionally disastrously non-foresight having. [laughs] I'm the dangerous one in the marriage. But she likes things with regularity. She was studying to be an accountant when we got married, and, I mean, that was about as much adventure as she wanted to have in her life was adding and subtracting numbers all day. Like, that's her idea of a good time, and, for me, it's mind-numbing. It's terrifying.

I say this because there are people who may be listening to this podcast who are listening to our stories of get contrasts, do these wildly disparate things. And you may be thinking, I don't want to do that, and that's fine. You don't have to do that. Do what you want to do. The whole point is to choose for yourself what is going to make you effective and happy.

MIKE: And if you've been spending all day adding, maybe you can spend some time subtracting.

DAVID: That's right. That's right. That big multiply and divide, whoa, whoa, whoa, let's not get crazy. Let's not get crazy. [laughs]

EDDY: I actually have a question; for those who have found comfort in working remote now, would you ever consider going back into the office?

MIKE: I think I'm the most remote person here, and I'd definitely consider it. Yeah, I enjoy interacting with my colleagues. The biggest downside, to me, to being in the office is probably the commute. There are distractions as well. But the commute takes some time every day. I have other reasons in that I live nowhere near the office. [laughs] And it's non-trivial for me to move for various reasons. But I would definitely consider it. I have no particular animosity toward the office.

DAVID: I hung out my shingle. We had a big tech recession in 2002 out here in Utah, and I got laid off from a government contracting job, and I hung out my shingle to do development. And I ended up landing a temporary gig, and then a remote gig, and then another temporary in-office gig. And I cycled. I would work from home for three months, then I would work in an office for six, and then I would work from home for nine months, then I'd worked in an office for four weeks.

And for me, it's all blurred together. Like, I have habits that I have learned to adopt, and it's just like changing your code. If it's raining, you put on your raincoat. If it's sunny, you put on a short-sleeved t-shirt. And there are certain habits that I have developed for in-office that I can't do when I'm at home. And there are certain habits that I have to adopt at home to be productive, habits that I cannot use when I'm in the office. And no, it's not just the whole wearing pants today. That's the standard joke about remote, right?

It's things like I don't have to be as conscious about socializing. I'm a naturally gregarious person. I like other people. Ironically, I'm an introvert. I don't seek people to recharge. But I'm a naturally gregarious person. So when I'm in the office, ironically, I actually have to check myself a little bit so that I don't end up being the distraction for everyone around me because I love being that guy. And when I'm at home, I don't have to worry about that.

But when I've been home long enough, you have to start seeking people out, or else you start going funny around the edges. You realize I have not stepped outside the front door of my house. And then you realize that your answer is the name of a month instead of hours. So, to answer your question, Eddy, yes, I absolutely would consider going back. I enjoy going back.

It's kind of like saying, you've been eating brownies. Would you ever consider going back and eating salad? And the answer is if you've eaten nothing but brownies for 18 months, you start gasping for salads. You're like; please give me a green vegetable. Please give me something with some structure and some fiber. And that, for me, is switching environments. There's definitely a sense of, like, if you're trapped in an office or if you don't know what it's like to get away from the office, you can be like, ah, I really, really want to try the greener grass on the other side of the fence. And it certainly...a change is great. And the grass is greener on both sides of the fence.

But having hopped the fence multiple, multiple times over my career, especially when I was freelancing, I had some customers who wanted me to freelance at their site and other customers who wanted me to freelance at home. So yeah, I've switched back and forth enough that, for me, it's just a change of wallpaper. There are coworkers in my wallpaper sometimes, not a sentence I thought I would say when I woke up this morning.

EDDY: I think I'm a little bit more on the other side of the fence. I wouldn't push back per se on going into the office, but I'm very comfortable with being remote right now. And I'm actually making plans to strive more in that direction rather than plans I'll ever have to go back, you know, just kind of got into my routines. It's definitely...I think I would look for the benefits companies that provide that remote work as a benefit type thing.

JASON: It's kind of funny. Anecdotally, my father in law in the pandemic...he's a very sociable person. When the pandemic hit, he was forced to work from home and was miserable. He was palpably irritable, just did not like it. He's one of those people who's got to be around other people. And I know a lot of people do this, but he, I mean, he already had a home office setup. But he went out and rented a space. We all kind of pitched him and helped move his office over so that he could still have a place where he could be...and he was still isolated and was as responsible as he could be with going through the pandemic.

But now it's kind of funny. He's since switched companies, and that kind of broadened his horizons. He has his own office now, and he ended up taking a remote job and still has that external office. He needs to get out and drive and get out. And I think it's for that mental health reason, you know, you need to contrast.

DAVID: Kind of a best-of-both-worlds situation.

JASON: Yeah, absolutely.

DAVID: Which, I mean, if you do it badly, you could turn it into the worst of both worlds, right? You could end up with a long commute to an office where you're lonely anyway. So yeah, if you do pick a co-working space, pick one that's close by. [laughs]

MARK: Yeah, I think for me, so I'm kind of like Dave. I've had both types of jobs. But I think over the last couple of years, where you've just been at home, it's still nice to go to the office, but I like the ability to do both, so combined. And I don't really push one way or the other. I do feel when I do go to the office, because it's not very often, it's a lot of catching up and talking, so I don't get a whole lot done at all. Then I go home and work for a couple of hours just to get some work done.

So if that's more consistent, I think that wouldn't happen as much. But I definitely like the ability to work from home. I got a dedicated office at home. I go in. I still kind of try to do, like you guys talked about, my same routine. I get up in the morning. I get ready for work, and it's ten steps down the hallway. And for me, it's not a commute. I'm five minutes from the office. So I don't have that excuse that it's a long way to get in there, but definitely like the ability to do both for sure.

DAVID: You just said something, Mark, that really hooked my ear there. What you said was you go into the office, and you don't feel like...you're socializing, and you don't feel like you get much work done. And, yes, in terms of advancing the project and meeting the deadline, that kind of work doesn't get done.

All the side things that we do that support work that are work-adjacent, like socializing with your co-workers, that might not happen if you're full-time remote. You do end up getting those things done when you're in the office. It doesn't come up in your performance reviews like, well, 20% of your raise is based on how much time you spent at the water cooler and how contributing you were to the conversation. That doesn't happen. But I think it's really, really interesting.

I had an event recently where I said something that was accidentally offensive to someone else in the conversation. And the timing of me saying it and the way I said it made it sound like I was intentionally trying to mock this person. And fortunately, I had spent enough time...I had not spent enough time with that person for them to know that I was completely not trying to embarrass them. I was not trying to point a joke at them. It was literally there were two completely different ways to interpret what I said. And I didn't realize that the offensive context even existed.

And they kind of took it as like, oh, that was intentional, or maybe you deliberately set up the double entendre because I use those in my humor all the time. So it sounded like I was setting it up. Fortunately, there were people in the room who went, "Dave." And I'm like, "What?" And they're like, "Did you..." And I went, "Oh my gosh, no, no," and I was able to back it out. But if I had not had socialization time with the other people in the room, they would have run me out of the group. And I think I would have deserved it, I mean, not in terms of my intention but in what I had done.

And all of that was due to time spent not doing work with these people but instead bonding and gelling with them and getting to know them and them getting to know my sense of humor. And also to know, I'm not super proud of this, but I will tell a joke with dirty words in it, and I will tell filthy jokes, not at work. But I don't like to tell jokes that are mean to people. And even if they're perfectly clean, I don't like to tell mean jokes.

And the double entendre that I made was mean in its other interpretation, and there were people in the room who went, "That's not Dave. Dave did not mean to say that." So they grabbed me by the ear and said, "Stop that. You need to go say you're sorry. Don't ask why. Just go say you're sorry." I'm like, "Okay." Sorry, that's kind of a weird tangent.

But what you said, sometimes we go to the office...what I would say is it's not that you're not getting work done, it's that you are doing different work-adjacent things. And when we work from home, there are other work-adjacent things that we can do. We can refill our emotional batteries by having access to our families or by being able to take the dog for a walk that we don't get when we're in the office, especially if we've got, you know, your commute is what? Like three and a half days if you jump in the car and head west?

MIKE: Right there. [laughs]

DAVID: Yeah. So, I don't know; I guess what it is is there's a contrast at work that is imposed. But there are other activities that we think of as, like, this is not part of the work. It's not officially part of your job description to get along with people and contribute. But it certainly shapes the direction of your career if you know how to socialize with people, if you know how to interact with people.

MIKE: Well, I would take that a little further. One of the things that I've seen be very effective at fostering remote teams is actively scheduling time, scheduling time to do, I would say, non-productive but to do things that don't create code [laughs] but are just there for social interaction. On our team, we've talked to some leadership about how to do this, actively been looking. What are some things we can do to let people have some fun together?

And that sounds maybe like a very forced way of making people feel like [laughs] it's a good place to work. That's really not the purpose. I mean, sure, we want it to be a more fun place to work. But, you know, if you want to go play games, you could do that at home too. Sometimes you got to have fun together because that actually has some real social utility. You get to know each other better and to trust each other sometimes by activities that are not just coding, and you have to make space for that.

Now, what that looks like for different people may be very different. There's a range of things that people may find appealing, and maybe some of the activities you do aren't what everybody would consider as fun. [laughs] It may feel like work. But that doesn't mean it doesn't have utility and value. Having every person on your team tell some interesting story about their background or playing some sort of group game together, not everybody enjoys those things.

Being put on the spotlight to tell something, and maybe you have a very troubled history, and that's very difficult for you. You don't want to put somebody in a really bad position, and so you talk to them first. But it's a level of uncomfortable and not painful, that's still uncomfortable. It may not even be pleasant. You may not be doing it for fun, per se, but it still provides value to the team.

DAVID: Yeah, finding that line between what is normal and safe versus what is slightly risky versus what is [laughs] way over the line, finding that. Having something that is just slightly risky or slightly vulnerable that you can share and if your team reciprocates that with empathy and compassion, that is a great bonding experience. If you never share that, your relationship will be kind of...I think antiseptic is the right word there. It's a little bit of wordplay, but it's completely true. If your work environment is emotionally antiseptic, you can never grow a culture.

JASON: Yeah, I know some of the social things that we've done on the Atlas team was, I don't know, a couple of weeks ago; I don't quite recall. We played a round of Codewords and just getting to know some of the interns that we had. And hearing them in kind of a new light and getting to socialize outside of the context of here's an answer to your question or some strictly informative conversation was fun. Like Michael Webster, one of our interns, he's hilarious.

I wouldn't have gotten to hear or understand some of the humor and jokes if we hadn't been socializing. And that's fun just to reach out and talk if you need something. It really kind of opens things up, makes things easier to even reach out to people in general when you have that social context or kind of friendship context.

DAVID: Absolutely. When you have a problem that might not be important...I shared a story before the call. I won't go into all the details. But TL;DR, I was having a problem that everyone else was having and was minimizing. And it was really making me crazy. And I finally compared it to someone else, and they went, "Oh my gosh, you have a terrible problem. Go take care of this." And because I knew somebody in the IT department, it was so much easier to just reach out and say, "Hey, Mike, what's going on with this?"

And to ask them is this, you know because this might be a low-priority thing. I don't want to go to the help desk. I don't want to open a ticket. I don't want to have, you know, full tracking on this. And he looked at that and went, "Oh yeah, that's serious, go open a help ticket. And I will jump on it for you." And I'm like, cool, we can follow the process and also have that monitoring and meeting.

Sorry to dovetail two stories back to back, but there's a pattern that's emerging from what we're talking about. We're all talking about time that we have spent in kind of play meetings as remote developers, which meant we had to make an appointment with each other. We had to schedule some mandatory fun, which just sounds like a death march, doesn't it? Doesn't it just sound terrible?

But my boss, Zack, isn't here today, so I can talk a story behind his back here a little bit. He invited me to come work on the data team. And he said, "We've got a really, really great team." And I said, "Great," and I came, and I joined the team. Now, we're coming off the back of the pandemic, and we're all full-time remote. And I dove into the data stuff that we needed to learn. And then, three months later, I realized I'd still not met anybody on my team.

And I had kind of a one-on-one with...not kind of I had a one-on-one with Zack. And I said, "You keep telling me this team is really great, but I've never met them." And the next day, there was an appointment on the calendar. For every other Wednesday for an hour, we're going to get together and just play games. And so I've been able to meet with my co-workers and hang out and tell stories. And find out, you know, some teams everything is straight-laced and starched collars, and other teams are, you know, the humor is very colorful. And I'm getting to find out what colors of humor are okay on this team. And it's been super, super, incredibly awesome.

So what I would say to any employer that's trying to figure out how do I grow a culture when everybody's remote, and we're unintentionally pouring, you know, antiseptic on places where we were growing culture, schedule some time. Don't make it mandatory. If somebody's pushing a deadline, don't force them to stress out about their job by putting down getting work done to go to some stupid meeting where people are going to joke around and shoot the BS when I really need to get, you know, don't make me do that.

But if you do say this is a meeting and if you come, you get credit for being at work, and you don't have to do work, right? We all, you know, sometimes like to take a fun break like that. Because he scheduled that time, I've been able to hang out with my co-workers. I'd still like to hang out with them a lot more, but I've now actually met them. I could tell you their names without [laughs] having to look up an org chart. So that would be my advice (Way too long of a story.), but yeah, schedule some time. Don't make it mandatory but make it fun enough. Make it attractive to people to want to come to the somewhat mandatory fun.

JASON: I think that's huge that you said, "Don't make it mandatory." I was going to say that that's a key component, in my opinion, of making it fun is they are there...people are participating because they want to be there and can be there. And they've never been mandatory, and I've never felt like they were mandatory. And most of the time, I haven't attended because there were other things that were going on. But knowing that it was there and the opportunity I always want to now, especially the last couple that we've done, it's been fun to be a part of, you know, if you can make it.

DAVID: I worked at a shop way too long ago, gosh, 1999, I think. They had a thing called beat burnout. And the fact that we needed it was a solid demonstration that they were...it was in the video game industry. We were working 100-hour weeks, except for when they wanted us to work more. [chuckles] And they would have beat burnout. And they would do big things. They were always off-site. We would rent out a movie theater and then go to dinner at a nice restaurant or go to lunch at a nice restaurant.

And we'd rent out the room at the place. Every summer, they would rent out the amusement park. There's an amusement park near here that is very expensive to go to. It's taking you and your wife and go to this thing is going to be, you know, or you and your partner and go to this thing it's going to be 100 bucks to go do that. And they're like, "No, you get in for free. We're going to run a tab at this restaurant inside the park. We're going to run a tab at this cafeteria where you can get snacks." Go have fun, and you get an all-access ride pass. And that was fantastic. It was really, really cool.

And I was way behind on a major deadline that was going to cost me my job, [laughs] so I stayed at home, and I worked through it. And there were a couple of other co-workers who also stayed at home because they don't like amusement parks. And they didn't show up at the office, and they got reprimanded. And we got an official note from the CEO saying, "If you are not at beat burnout, you must be at your desk working." And attendance at beat burnout fell through the floor.

Even though they were doing great, fun things, after that, people were like, "Screw you, guys. I don't want to play this game." I do not want to be handcuffed to the roller coaster, which in this case is a literal roller coaster at an actual amusement park where you're supposed to be having fun.

EDDY: Basically, all I've gathered from talking to you guys [laughs] is that people can be less productive while in the office. So my question is, how the heck were any of you guys getting the job done before the pandemic?

DAVID: Oh, I wasn't. I wasn't.

EDDY: [laughs]

DAVID: The reason I had so many jobs is I'd go to a place, I get fired. No, I'm kidding. I'm kidding. It's different work, right? It's a different way of approaching. When I go into the office, I don't have to structure my day anymore because I have to be there at a certain time. That means I've got to get up at a certain time, take a shower, get dressed, eat some breakfast. I've got to commute at a certain time. And that structures out my day. Lunchtime is a certain hour; go home at a certain hour. And that gives me some of that necessary structure to my day, some of that necessary contrast to my day.

But when I work from home, there's this wonderful thing where sometimes the structure has sharp corners, and that corner is going to gouge straight out of my eyeball. Instead of supporting me and giving me a framework to support my day, it's an overhead beam that I smack my head on. And it's just emotionally taxing, and it takes ten times as much emotional energy to be present during this particular hour of the day where if I was at home, I could...you know what? I really need to just go take a nap. And I can't do that in the office, that kind of thing.

So knowing what things you have to build for yourself in each environment is crucial. Knowing what things can support you in each environment is crucial. And they are different things, and you can be productive. There's a book called "Peopleware" and a software called Peopleware and a company called PeopleSoft, I think. But there's an old, old book...I can't remember the names of the authors. But the book is called "Peopleware." DeMarco and Lister, I think, might be the authors. They wrote this book in the '90s, and it was all about how to be productive, how to manage people in a technological environment.

And their premise was technology does not solve any people problems. It doesn't solve any human problems. It just makes them happen faster. And there's just one sentence...they were walking through studying this great big cube farm. And the boss was giving them a tour of the place, and he was saying, "I like having everybody here in the cube farm," and they had low-walled cubicles. "I like the low-walled cubicles because I can look out over and I can see who's working and I can see who's not because I've got to stay on top of these people to keep them busy and keep them focused and on task."

And as they walked, they noticed...they looked into one of the conference rooms, and there was an engineer in the conference room with papers strewn. This was before laptops. This was in the '90s or '80s, sorry. He had papers strewn all across the conference table and was poring over them intently. They took note of it, and they continued to tour. They dropped the CEO back in his office and said, "If you don't mind, we'd like to tour your office unsupervised." And he said, "Sure, go on. I got nothing to hide."

And they went straight back to the conference room. And they poked their heads, and they said, "Sorry for disturbing you, but why are you in the conference room?" And he looked up, and he said, "Oh, I'm hiding in here." And they're like, "Why are you hiding in here?" And he said, "So I can get some work done." And that became kind of the spark for these guys to go write this book because they realized there's this boss who thinks all of his employees are lazy and distractible and work-shy peasants kind of thing.

If that's true, why does he have people that are sneaking off to quiet rooms so they can get work done? Maybe we need to think about work in terms of maybe employees actually want to get work done. Maybe if we want to accomplish things in whichever environment you're in, we need to empower that and make that happen. So that was kind of a long, wild, rambly tangent. I highly recommend the "Peopleware" book if you haven't heard of that or haven't read it.

To give you an idea of how...I want to use the phrase eternal truth. [laughs] It's a phrase of, like, how long-lasting their advice and how evergreen their advice is. They wrote the book before the internet existed. And when the internet came out, they went back to them and said, "Okay, okay, you studied those people without computers in their offices and all these things. Now that the internet is here, we need a version 2.0 of the book that changes all the things that you've learned about how people are productive and how they think and how they work."

And they went back and went through their book, and they compared everything to the internet age. And they added half a chapter on dealing with the distraction of email. And they said, "Other than that, the internet has done nothing to the things that we said back in the '80s. People want to get work done. And if you throw technology at them, it just distracts them," which I thought was fantastic and fascinating.

KYLE: I'd like to throw my two cents on Eddy's question too.

DAVID: Please do.

KYLE: What I've kind of noticed is when I was in the office, I would get work done, but there was the quote, unquote, "water cooler time." And this kind of goes back to Mark's concern when he goes in the office. I think, yeah, I do get more work done when I'm at home. But I think that water cooler time you'd have everyday kind of builds up to where if you're going in every once in a while, it appears as though you're not getting anything done in the office because all that water cooler time has built up, and you're getting it done in that day or in the few days that you are there that would normally naturally just be getting done day by day if you were there in the office every day.

I've also seen, too, a lot of the older offices don't have them, at least from my experience. But the newer offices, like when I was at InsideSales or the new building that we went to at Acima, they've got these isolated self-cube rooms. I'm not sure what to call them, like, solo conference rooms or whatever. And part of those, at least from my understanding, is if you need to get away, if you need to be isolated, you can go into those rooms and work, and those are there for a reason because there are distractions in an office. You need somewhere where you can just go and be heads down.

And I think that's just a trend that has kind of taken off in the technology space. I don't know how common that is in a normal office environment outside of technology, but I've definitely had to use those a few times just to, okay, I need somewhere where I can't be distracted, which is something I don't need at home. I can just close my door, and nobody comes and bugs me.

DAVID: I've worked at a couple of shops where they moved to an open floor plan or what, agile with a lowercase a, what agile refers to as a bullpen environment. And the idea in the bullpen is to make it so that everybody overhears everything because it's valuable. It's like, "Oh, man, I can't connect to the database. Can you connect to the database?" And somebody two seats over goes, "Oh yeah, they changed the connector from eight-bit to seven-bit. Turn on parity, and you'll be fine."

There's like this side-channel thing. And they just saved you three hours of debugging, and it's fantastic. The problem is that you're trying to solve this problem that's like seven layers of recursion deep. And the person three chairs down says they can't connect to the database. And you know the answer, so you're going to tell them. Well, you just got distracted.

And in places that have bullpens, the chief complaint is you don't have any place where you can go to think, and especially you don't have any place where you can take a phone call without disrupting everybody around you. And so what I've seen are open floor plans with little three-foot by three-foot or four-foot by four-foot cubicles. They have a door. They have a big, tall window so you can see if it's occupied. And it's just enough space for a laptop and for you to put a sheet of paper next...and it's tiny. It's a tiny, tiny room. There are no monitors in there.

But notably, there's also acoustic foam on the walls so that if you want to take a phone call or if you want to jump on a podcast with somebody and you're in the middle of a bullpen, you can go to the privacy rooms, booths, really like little phone booths all along the side. I thought that was a fantastic way to make it so that you could elect whether you wanted zero distractions for an hour or whether you wanted to take a phone call without distracting your neighbors. I thought that was a neat way to deal with that.

JASON: It's kind of funny how ironic that is that you build offices to get people into the office to work so they won't be distracted, and now we have to build sub-offices essentially where people can go to be alone and work.

DAVID: [laughs] Was it George Carlin that did the joke about humans didn't like it was cold, so they built a box to live in where it was warm? And then their food went bad, so they built a box inside the box to keep things cold. And then, the butter kept getting too hard, so they built a box inside the box inside the box to keep the butter warm. Those booths are basically the butter dishes of our office complex. [laughs]

JASON: True.

KYLE: And I've always thought the idea of a bullpen was kind of funny because you build the bullpens so that the communication can be heard, and then they complain about it being too noisy. And, at this point, I've never been in a bullpen that hasn't had a white noise generator.

DAVID: Oh.

JASON: Well, you and me were both in sales, Kyle. And it's funny because you have everybody in that environment, and you have merchants who are getting this or retailers rather that we work with who get some background noise. So it's kind of funny. I'm sure that's changed since the office is larger and you have those white noise generators. It's kind of ironic, I guess.

DAVID: I will say that in my experience, bullpens don't work well once you've got more than about ten people in it, also, if it's a focused team. If you've got 30 people in a room, and you've got the IT team, and you've got the sales team, and you've got the engineering team all working in the same room, then the things that you're overhearing have nothing to do with your job, and they're just pure distraction.

I believe that white noise generators are of the devil. They're just the most evil thing in the world. The auditory processors in your brain cannot shut off. And any species that shuts off their auditory processors while they sleep are now extinct because they get eaten in their sleep, and humans are no different. That part of your brain never ever shuts off. And so if you put on white noise to sleep or put on a fan to sleep, it doesn't give you as restful sleep as having total silence.

And trying to think about an engineering problem...I have ADD. I love having music on. I love having people to talk to. I love having stuff. And I had to train myself to sit in silence, and when I did, I noticed I had an extra 40 horsepower in the brain engine compartment. That's a weird metaphor. You can think better when you free up those neurons. If you have an open bullpen to encourage communication, and then you turn on a white noise generator to jam communication, fire your floor planner, please. Just, yeah, give people offices at that point; give them silence when they crave it.

MIKE: So, as we're finishing here, I'm noticing a recurring theme about being deliberate about things, scheduling time, creating spaces to do things. And this applies not just to remote work but in-person work. And it's been about the need to have some structure that it's...I'm going to say mandatory, but it is not the best word for it. If you want to be successful, you need a surprising amount of structure. And it can be completely and probably should be self-imposed. But you're making that choice for yourself so that you can be effective.

DAVID: Absolutely. When I try to schedule my exercise, I hate doing that. So I look at it from the thing of, like, I want to fill up this bucket with this much quantity of exercise over this amount of time, which makes it nice because now if I fall down the rabbit hole and I start chasing this really interesting problem at work and all of a sudden I accidentally seven hours, I don't feel like, oh, I missed my workout time. It's like, oh, no, I wanted to do some walking today, and I've got a minute now. I'll go for a walk.

And at the end of the week, if I haven't done much walking that week, I can say I need to do more walking this week. That's my way as a very fluid kind of eclectic person of saying I'm going to own my schedule because I can say I want to put this in my schedule, and I want to get it done. But I don't actually need to make an appointment for it. And if somebody else makes an appointment for something to happen, I absolutely am going to resist that because of just the way my ego works.

MIKE: Either way, though, you did set some time aside to yourself. You did it in the way --

DAVID: Yeah, yeah. I am 100% agreeing with you that what we're touching on here is owning the schedule, and owning your life, owning your career, owning what you do in a day, 100% agree, yes.

JASON: Can say I love how Acima has done things, kind of putting the ownership on the engineer and the employee.

DAVID: Yeah, trusting people to get it done, and then people get it done. And it feels great. Well, fantastic. Ramses had to drop off a minute early. But Kyle, Jason, Eddy, Mark, Mike, thank you so much for coming. This was a lot of fun. And I'm looking forward to our next episode. And we'll see you guys soon.

We enjoyed the last episode so much we're continuing the conversation with even more of our favorite dev tools and tricks!

Transcript:

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.

We're calling out the most valuable development tools and tricks.

Transcript:

MIKE: Welcome to another episode of our Acima Development Podcast. I'm Mike. I'll be hosting today. And today, we're going to be talking about development tools and tricks. Before I do that, I'd like to go around and have everybody briefly introduce themselves. Mark, do you want to introduce yourself?

MARK: Hello, my name is Mark. I'm an intern for the summer.

MIKE: Thank you. Jason.

JASON: My name is Jason. I've been developing for about six months now. I started as a developer here in Acima.

MIKE: Great, thank you. Ramses.

RAMSES: Hello, hello. I have also been a software developer now with Acima for about six months.

MIKE: Great. And Kyle.

KYLE: Hey. Kyle, DevOps Engineer, been doing that here at Acima for about five years.

MIKE: So now that we've introduced ourselves, I wanted to start with not quite a story; it's an example. I'm interested in pedagogy, in teaching, in the science of teaching, and I've read quite a bit about math teaching in particular. There's a popular technique that has become more popular in the most recent few years to help children develop the appropriate mindset, and it works for adults as well, develop an appropriate mindset for math because, a lot of times, we're taught mindsets that are not very helpful.

Learning math by rote, in particular, tends to lead to difficulty solving novel problems. You run into a new problem like "Oh, now what do I do?" And professional mathematicians approach math very differently than how it's often taught in schools. For them, math is art and creativity, and looking for interesting new ways to approach problems, where a lot of people who are taught math in school are taught very differently, where here's your problem; here's the technique for solving the problem. And that's the one way to do it.

So in order to develop a better mindset, a more flexible mindset for teaching, they do what they call number talks or math talks, where you present a math problem that you can solve in your head with some challenge. How would you add 23+84 in your head? And you ask a class of 30 kids this, and you get like 32 answers. [laughs] Everybody does it a little bit different. And I may be exaggerating a little bit because you'll tend to have common themes.

But it's remarkable how people will come up with very different ways of doing it; some people will add the tens first and then the ones. Some people will try to get to easy numbers like multiples of 25, or multiples of 5, or multiples of 10 and then balance out the numbers accordingly. Some people might go to 100, you know, they work around boundaries like that. There are lots of different ways that people can approach problems, a surprising number of ways people can approach those kinds of problems.

And once you hear all the other different ways, you're like, wow, I thought there was only one way of doing it, and I thought that it was just my way. And it turns out there are many different ways of solving the problem. It's worth looking up if you're ever interested in thinking about it. It's fun to try it with a group of friends. Just come up with a problem like that. Just do some addition or some multiplication that you can do in your head with a bit of challenge, and ask other people how they do it. And you'll likely be surprised how many different ways people do it.

I used this introduction to come into software development tools because, coming into the industry, you might think there's one way to do this. But our industry is a creative industry. Our job is not to follow a set of rules but to solve problems. I'll repeat that repeatedly, and I've probably mentioned it other times I host the podcast because there's a misconception sometimes that our job is writing code, which is not really true. Our job is to solve problems.

And there are a lot of ways to solve the problem. And you may have people who approach the problem in very different ways and come up with a great solution through very different techniques. And that doesn't mean that one is right and one is wrong. So there's some real value in seeing a variety of ways to find out what works for you. There's not necessarily a right answer. Sometimes there may be solutions that are not very good, and it's good to recognize those.

But, in general, there's a lot of gray area there. There's a lot of flexibility and areas where there's not really a right or wrong answer, just a variety of answers. And having a whole toolbox with the tools rather than just one hammer is going to give you a lot of power to do things differently and likely do things better because you can reach for a variety of tools and find the right one for the right place. And you may find that your personal preferences lead to different approaches from what other people do.

I'm going to lead by saying that I am very much a minimalist. I used to use big IDE when I was a Java developer years ago. That's pretty common in the Java world. And I did a lot of remote server administration for a while. I started using command-line editors and just stuck. So I'm a Vim user, primarily, and have been for a number of years, which is just a command-line editor. I never leave the terminal. I rarely leave Vim because I can execute commands from right inside Vim.

I don't have a lot of plugins and just use the standard Linux or Unix toolset that is available from the command line to do my searching, and I find it extremely effective. I'm able to navigate around and find what I need very quickly. Others use a big toolset and are able to also navigate around files and find things very quickly. I'm not going to say one is better than the other because I think they both have merits.

So I'm going to start with just saying I tend to be a minimalist. I'm curious where other people are at because other people have their own tools that are very useful. I will say that knowing at least one command-line editor...and the two big capable command-line editors are generally Vim and Emacs. It's a surprising superpower. It takes some doing to learn. But those tools allow you to accomplish a lot with a little. And even if you don't get really good at them, it's nice to have those in your tool belt so that you can accomplish something.

So if I were going to start by saying a very useful tool, I would recommend learning a command-line editor. And if you want an easy introduction, there are very easy command-line editors you can start with, like Nano, which is a simple editor that once you get into, you'll be able to see how to get out, unlike Vim. [laughs] And you can get started that way. I think there's a lot of value in using those command-line tools.

I would like to talk more about the incredible value of the command-line tools that come from Unix, particularly grep. Grep is the open version of this that's widely used on Linux that I think are invaluable for myself in my tools. But I don't want to talk the whole time. So I wanted to lead with that, talk about the importance of a variety of tools and start my take on useful tools by saying to anybody that command-line tools are, in general, incredibly valuable.

And I'll talk a bit more about that in a minute. But I'd like to hear what other people have to say about what, you know if you were to just...if somebody was to ask you, "What is most valuable to you?" what would you say is the most valuable tool?

KYLE: I'll have to agree with you on the Vim subject. And I have been around the Emacs people as well. And I feel like that requires a different set of joints in your finger to use that tool.

MIKE: [laughs]

KYLE: But I come from the other side of the fence as well, though, because starting out in QA, a lot of the tooling that I was introduced to that made my job easier and flow well was all GUI-related and Git from a UI and stuff like that. The transition to using something like Vim, I wouldn't say I'm any kind of expert. But I feel like it's made my job so much easier in the sense that there is native tooling, like you were saying, grep, and everything in Linux and Unix that you're able to do that's even cross-platform.

A lot of what you're going to find on Linux is available on a macOS or even in the later versions of Windows. Now you have that ability as well, either through PowerShell or through the Linux Subsystem that they have now. It's just I do feel like my productivity has increased. And the scripting and the tooling that you're able to use, even with just a Bash application, you can just do a lot that you can still do with a UI as long as you're really familiar with the tool.

MIKE: A lot of things you can. There are some things that are actually remarkably difficult, if not impossible, to do from a UI. I don't want to get to the punch line because [laughs] I want to hear what a couple of people have to say. But I'd like to grab back onto that thread because I am with you completely that it is useful, and you can do it from a UI if you're familiar with it. But there are some things that I think you can't in most UIs to accomplish. Again, I'm going to come back to that. I'm curious. Jason, I think you were going to say something.

JASON: Yeah, I think it was drifting a little further off-topic from a specific IDE. But a really useful tool that I had when I came on, Johnny actually pointed out. And basically, he showed me where I can customize methods anywhere. I run Pry or anywhere I run an IRB console. So just knowing where you can add those custom methods is really a time saver and kind of lends itself to what you're saying, you know, running things from a command-line editor or a GUI.

Right now, I'm using RubyMine. It seems to be popular with a lot of the devs and has a lot of useful tools, and being newer, that is helpful. There are a lot of helpful hints there. But yeah, being able to modify your pryrc file or irbrc file to add some custom methods to help you save time has been big for me.

MIKE: Thank you. And anybody listening who's not a Rubyist, Pry is a popular Ruby debugger. You can use it on the command line.

ZACK: So one of the big things that have always gotten me throughout my development career is merge conflicts. And the tool that I found that I've just hooked into the terminal so I can just run git merge tool and pops up is Meld. I don't know if any of you guys have ever used that before. It kind of does pop up like a UI for you with some easy arrows to just kind of push and create one file with the right edits to it. And it's been kind of a lifesaver as far as merge conflicts have gone.

MIKE: Merge conflicts are the bane of development. [laughs] Anything you can find that is useful for those is good. We could have a whole episode on Git and ways to deal with merge conflicts and avoid them before they ever happen. Thank you. Anybody else who wants to share a tool that just really is the best one that they use?

MARK: For me, it'd be VS Code open-source code editor that you can pretty much do anything you want in. And the only problem I would give with it is that there are sometimes troubles with its terminal. But besides that, I find it's a great source for editing code as well as the ability to customize the interface and so forth and style it as you like.

MIKE: I feel like VS Code has kind of taken over the world. [laughter] It seems to have become the editor of choice for a lot of people

MARK: Well, more and more people are pushing for open-source products. I think Germany swapped all their government computers to Linux. Or was it that they put their whole school system on Nextcloud?

MIKE: I know there have been several experiments in Europe like that. I haven't followed it really closely. Definitely, you know, open source is helpful. And they've got a big corporate backer for VS Code as well, so it keeps it going. And we've also got some interesting integrations now with Copilot, some very interesting things with that IDE. They're very cool. So there's a lot of innovative stuff going on with VS Code. And it seems to be where a lot of the energy of the industry is.

KYLE: Just wanted to pop in and say something about VS Code just because that is another tool that we heavily use with DevOps because, once again, it integrates with everything under the kitchen sink. Just...and, Mark, I don't know if you've tried it or not, but you can basically use any terminal with VS Code. You just have to go into the settings and pick which one you're wanting to use if that helps you out at all.

MARK: I'm aware. It's just there are some times where I've run into a permissions issue where it'll say, "The terminal within VS Code has less permissions," then just pulling up the terminal app.

KYLE: Ah, okay, yeah. It can be limiting at times.

MIKE: Well, with that segue going back to terminal, I want to revisit this idea of command-line tooling versus user interface. There is a philosophy embraced by the Unix operating system. Nobody...well, I say nobody...the original Unix operating system birthed many children. And while pure Unix is not that widespread anymore, it has many of these children. I believe that macOS is formally certified as a Unix and meets the requirements for Unix, even though it has a very different underlying system.

And Linux is Unix-ish in its approach, even if it was built from scratch. And it's taken over the world. Android runs on a Linux base. I'm actually not that familiar with iOS, and it wouldn't surprise me if they used something similar. Because most of the devices out there in the world run some Unix-inspired operating system, and I think there's a reason for that. There's a Unix philosophy that says the tools should be small, single-purpose, and composable, all of which are important.

I say small, meaning that they don't do all of the things, although some of the...like an editor, maybe does a lot of things. Emacs, there's very little it can't do. [laughs] Some people see it as unwieldy, but it's a very powerful tool. But most of the tools they use are single-purpose. You might have a tool, for example, that counts characters or a tool that just runs regular expressions to search for text within a string.

And the single-purpose tools are composable in that Unix allows you to create what they call a pipe, which sends the output from one command as the input to the next command, allowing you to chain commands together and compose an arbitrary number. And you can put 50 of them together. There's no real preset limit. You can take the output from one command and put it as the input into another. And, okay, that sounds simple enough, but it is radically more powerful than other approaches, and I'd argue that emphatically.

Because if you've got a graphical tool that lets you do a thing, maybe it lets you do a sophisticated thing, you can get whatever you can get from that one tool. But instead, if you have a simple tool, instead of doing some very sophisticated thing, it does one thing well. And it allows you to compose it with other things that would accomplish the same thing.

You can almost always do what you're able to do with that graphical tool but then take the output of it and send it to another tool. So you can take your sum that you got from the first tool and send it into the next thing to do some math on, and then send it to the next tool to print it out to a file, write it to a file, and then you can even send that file as an email. You can chain these tools together to come up with a very sophisticated workflow.

A lot of times, just in development, you want to do simple things. What if I want to look for all the files that have a particular extension and, for each of those, search for a particular line of text, and then compile all of those files into a list and open them up in my editor? I do things like that all the time using my command-line tools. It is very useful. And that's something that's actually very challenging to do using a graphical tool and may not be even possible in most of the tools that you use unless you've learned how to use some obscure tricks in the edges of it.

And that's why I say that these command-line tools are, I think, underappreciated, and the most important tool, I think, that is worth developing and getting in your tool belt as a developer because they are much more powerful than most other tools available and faster as well. And, Kyle, you talked a little about the power of command-line tools. Has that been consistent with your experience?

KYLE: Yeah, that's along the lines of what I've experienced, too. I was actually sitting here thinking, as you were talking, there are CLIs for everything almost. And, I mean, if you're looking at a...not to bash on any particular company, but you go in, and you'll see a UI, and you'll familiarize yourself with the UI. And then four months later, if we're looking at long-term or whatever, you go in there, and it's like, oh, we've got a new look. And you're like, well, that's great, but where's this setting, or where's this feature that I was looking for, right?

MIKE: Right.

KYLE: And with a CLI, I've found that doesn't change; that's constant. They may add features, but they don't really move them around. And I feel like that's another power of the command line, if you want to say, is each of these companies are making CLIs that they will do the same thing, call the same APIs is what, you know, either their application or web interface will do. And you're able to do a lot of the same stuff easier and faster than you might be able to even find it in the UI.

MIKE: I agree 100%. Just anybody listening who's not familiar with the lingo, when we say CLI, we're talking about a command-line interface and using something from the command line. I'd ask that further, Kyle, from the DevOps perspective, which would you rather have: configuration files that you can manage through Git or, I guess, there are other source control tools, but nobody...I'm not going to say nobody uses them [laughs], but Git has kind of dominated source control. Would you rather have configuration files and scripts managed in source control or a pipeline managed in a graphical user interface?

KYLE: I avoid a graphical interface as often as I can. It's all about having configuration management.

MIKE: Yeah, there's a reason that DevOps has become central to, I think, most effective software companies. They treat configuration as code and use the same powerful tools that we use in development to great effect.

KYLE: It's just one of those situations where, I mean, here at Acima, we've got...what is it? Five or six environments. And so, I can either go in and configure each environment through the UI, or I can configure one environment in configuration and apply it to every environment with a quick script. And it's which one would you rather do? Which one's going to save the company money and make you look better in the long run?

MIKE: [laughs] Absolutely. We touched on something there that we didn't dig into. We've been talking about command-line tools and their great utility. We talked a little about Linux. But there's another incredibly powerful tool written by the same guy, Linus Torvalds, who gave us Linux. Linus Torvalds started Linux [laughs] but has personally not, by any stretch of the imagination, written most of it. His gift to the community was planting that seed and starting that community, which together builds a remarkable tool.

He also started another tool that has become fundamental to, I think, most development companies out there which is Git. It's kind of a silly name, incredibly useful tool. [laughs] And maybe it'll be superseded by some other tool in the future, but for now, I think Git sort of reigns supreme. You can use graphical interfaces for Git. I actually don't, like, ever [laughs] because its command-line interface is very powerful. But graphical interface, there's nothing wrong with them; they work great.

And having that powerful version control system is, I would say, a vital tool for effective development. Those of us who have used, I would say, inferior or simpler tools in the past know the treasure of everything that Git is. And Git is actually, at its core, a pretty simple idea, which is instead of having a central repository that has a single point of failure, everybody keeps everything.

You keep a history of all of the changes that have ever happened to your project. So you have basically a stream of events that are signed so that you can verify them, going back all the way through the history of a project back to the beginning. And everybody keeps that. And by having it distributed, it's very hard to lose very much that's important.

Maybe you've been working on a project for a couple of days and kept it on your own machine and didn't share it out with the community, and maybe you'd lose that. You don't need to. You can push up your changes hourly, and then you're unlikely to ever lose very much, and certainly not the whole project. And Git manages that distributed system of multiple copies repository and manages to handle it very well. And in doing so, it has become a central tool to most development. And there are business models built on top of this open-source tool, such as GitHub. What would your lives be like without Git?

MARK: A big pain in the ass for managing.

MIKE: [laughs] Yeah.

JASON: A lot of re-dos.

MARK: We'd probably have something like daily merge meetings just to begin work together to merge all our changes on everyone's devices.

MIKE: Oh. I think that's exactly right. You'd do daily merge meetings, and you'd have to carefully coordinate. [laughs] Let's make sure that you never touch the same code as somebody else. And it would all have to be done by direct communication. You'd have to talk to somebody first to coordinate that. No easy way to handle conflicts when you both accidentally change the same file. Nightmare. [laughs]

If you're starting out at development, start using a version control system. It will serve you well. It will save you pain, as Mark said, and re-dos, as Jason said, more times than you will ever count. It's just a remarkable tool. And there are some other systems out there. Git is the most popular and extremely useful. There are a couple; like I said, there are a couple others. Mercurial is used somewhat. It has its own following.

JASON: One added benefit to that is you can have kind of this fearless sense of I can experiment, do whatever I want. I'll just create a new branch and experiment and see if it works.

MIKE: And it changes your mindset, doesn't it?

JASON: Absolutely, yeah. Also, this discussion is kind of interesting because I never really thought of source control giving you that liberty. I'm not afraid to touch any file. I can do anything that I need to so long as I'm not modifying something else, like a database that could set me back, but even that, you can reset to a better state.

MIKE: I love where you went there. It gives you freedom to experiment. Freedom to experiment is one of the most important things for being able to be effective as well. It's closely related to the idea of psychological safety, which research has shown to be the central characteristic of effective teams and effective developers. If you can feel free to experiment without harsh consequences, then you're going to, and trying new things is how you get things done. I think we could talk about this for some time.

I saw a wonderful presentation at a conference once talking about luck. And I'm going to summarize the presentation, and you can go and look it up yourself. But there was some research done about what makes people lucky. They asked people who of their friends was lucky. So they characterized a group of people who were considered lucky by others. And they figured out what was different between these lucky people and other people to actually research what makes a person lucky. And you can figure out what the difference is.

It turns out that the key differentiator between lucky people and people who are not so fortunate is that the lucky people try new things. And when I heard that, I maybe paused; oh, really? I've thought about that a lot since. If I want to be lucky, I got to try new things. You're never going to have a different experience unless you're trying new things. Yes, you can have some bad experiences too, [laughs] but you're never going to get something that will take you to the next level, have that moment of serendipity unless you are putting yourself in a position where you can. Git allows you to be lucky.

KYLE: Just a side thought on this as we're talking. I almost feel like Git, or a tool like Git, is partially why some of us can be employed I feel like. Because I just feel like if you didn't have a tool like that, large development teams would be a burden more than anything. You'd have small, concise teams that don't, you know, one dude is working on something, and then the other person is working on something else. And they can quickly merge things.

And we wouldn't be able to have 7, 10 developers, whatever, working on the same service because they would be having those conflicts, and it would be just a managing nightmare. So I think part of this is that it gives us that parallelism to allow more developers to be employed to deliver faster and everything.

MIKE: Well-spoken. Going back again to that capacity, it'd be utterly unmanageable without the tool.

We've talked a lot about the power of the command line and the power of version control. I think I mentioned one command-line tool that, for me, is perhaps my favorite, the one that I use all of the time and I think is perhaps under-appreciated, which is grep. I mentioned it previously. Grep is like a utility knife for search. [laughs] It has all the various different tools out there that you might need to use.

It's a fairly simple tool. It searches using simple expressions, generally uses regular expressions. You can specify how much it leans toward regular expression versus just simple text search. Regular expressions are a little mini-language for search that are used widely throughout the software industry, including in tools like grep.

And using that tool allowing you to search on the command line is amazing because if I want to search for, say, a string within a set of files, I can use that tool, and maybe I'll get back 10,000 results, way more than I wanted. But then I can pipe that into another usage of grep that reverse filters for some string that's common that I don't actually want in my search. And maybe I'll chain three or four of those together because I'll run it and see my output, like, oh, wait, I've got this other string that is always there when I'm actually looking for just a substring of that. And I'll just keep adding to my chain.

And maybe eventually, I'll get to a chain that's 10-long where I'll filter things out that I don't want, starting with something that I do want. And maybe at the end, I add something else that I want, and I'll get back a small set that gives me a list of files. And that chaining is remarkably helpful. And some IDEs, I think, support this idea of chaining.

And I think internalizing that idea that I don't have to do it all at once. I can do this in incremental pieces and chain them together to get what I want is remarkably powerful. That is very powerful for grep. But it's also powerful in a lot of other contexts. Thinking about this pipeline of chain commands that progressively filter and transform what you started with leads to an incredibly powerful tool. Any other heavy grep users here?

JASON: I use grep specifically every day.

MIKE: It's a superpower, isn't it?

JASON: It's a time saver. It's nice. That's one of the things that it's kind of funny. I'm starting to see why people transition away from a GUI to command line, or at least now, whereas before, I didn't always have my terminal open. My schooling was in Java, and it wasn't super handy having the terminal open, at least not for me. I wasn't experienced enough. Definitely, now it's constantly open, and I'm, again, starting to see that transition because it's just so much faster. Maybe that's why Ramses could get so much done, superuser.

RAMSES: Yeah, I don't use any graphical interfaces; it's all Vim.

MIKE: It's just so much faster, isn't it? [laughs]

RAMSES: Yeah, incredibly. I've tried to use different graphical interfaces like RubyMine and VS Code, but they just slow me down.

MIKE: That's where it got to for me; I mean, I used to use an IDE all the time. And after using a console-based editor heavily, when I tried to go back, it was painful. [laughs] This is just so slow. There are very good uses of graphical IDEs, though, that can become quite effective. Again, there's more than one way to solve this problem. But people who go to the command line, I think, in general, get very fast. [laughs] It's worth doing. It's worth learning, even if you don't use it all the time.

We actually had a late joiner who spoke up once, Zack, who works on the data side. I'm very curious because we've got mostly traditional developers. But data has kind of taken over the world in the last few years. So I'd be really interested to hear, Zack, what you would consider some of the most useful tools. You talked about using tools for solving merge conflicts. I would guess that you have several other tools that you might see as vital. If you don't mind, Zack, what you mention might be useful tools from the data side that the rest of us might not be familiar with.

ZACK: I use mainly the JetBrains suite as far as IDEs and stuff go, specifically data-side, DataGrip to be able to just access all the databases, look at data like that. I don't necessarily really have tools that go through the data. It's all just queries that I have to write to find outliers and stuff like that. So DataGrip is just extremely helpful.

MIKE: That's interesting. So I'm assuming that SQL is your best friend.

ZACK: Yeah. Yeah, yeah. If you take a look at how our scripts function, we use Python, but it's really just like a gateway to SQL. Most of our stuff is just random straight SQL.

MIKE: SQL is SQL, S-Q-L. I'll use whichever one the person I'm talking with uses, [laughs] but it means the same thing. It's not necessarily the latest, greatest, most trendy language, and it's probably got some rough edges even. But what an incredibly powerful tool.

ZACK: Yeah. There are very few things, in my opinion, that Python or really any language can do that you can't just do in SQL as well, as it's extremely powerful for that data and never even leaves the warehouse, so you have no network latencies. You have none of that working against you. It's all just happening in the same place.

MIKE: I think that can hardly be overstated. But most operations, if you can keep them in the database rather than bring them to the client side, you will save yourself multiple orders of magnitude of time.

ZACK: Yeah. And there's still...with warehousing; it's typically a cluster of machines, whereas I believe maybe our Postgres instances are just one machine. So there's still a little bit of network latency that happens, even processing just within the warehouse. But it's so small because all of those machines are sitting right next to each other. But yeah, you can tell a massive difference if you were to run a query that pulls data out versus just run a query that creates a new table. It's night and day difference for sure.

MIKE: One thing I've noticed working with a data warehouse is that, as a general rule, all queries take a few seconds. You run a simple query to return a few records, and it takes a few seconds. You run some incredibly sophisticated query that does all kinds of complicated things, and it might run a few seconds. [laughs]

ZACK: It's kind of funny because those complicated queries that you're talking about will probably return faster for you than SELECT * from, just the way that a columnar database is geared towards a row-based database such as Postgres where the whole row is sitting right next to each other. But, again, in a data warehouse, it has to go search all over disk to go find all the different columns to combine them back together. So the most powerful tool [laughs] in my arsenal is the warehouse, very specific type of database.

MIKE: Yeah, I first started using a columnar database ten years ago or something, and it opens up a whole world of possibilities. When you just have your online transaction processing database, just your standard database, and you want to run some big, ugly query that you know is going to run slow, you pause. Can I really run this, or am I going to take down production? And the answer is, yeah, you probably shouldn't run it. And then your hands are tied. And what do you do?

And if you have a replica, then you run the query, and it works. But again, if you're running just a traditional row-based database, it might not ever come back. It might run for several minutes. You just run out of memory. It's not designed for that kind of use case. But when you have this other database that is configured differently and designed for running those big, ugly queries, it's not going to be very fast for, like you say, SELECT *, you know, return this one record. It's going to be slow. You never want to use that for your production database. But if you want to run a report, it's transformational.

ZACK: Yeah, it gets really, really powerful once you start separating compute and storage and all that stuff. And you can really have machines that are just specifically made for one purpose rather than just having one machine stood up that's really made to try to handle everything. Plus, just getting distributed computing going is a massive win when it comes to data.

MIKE: And those who haven't used it, it's hard to express the difference between waiting for 20 minutes for a query that times out and waiting 5 seconds then you get your results back. It allows a different cadence to your work. If you can do something 1,000 times a day versus 3, it's a different kind of work. It's fundamentally different in character. Sounds like you're going to say something, Zack.

ZACK: Yeah. My last job that I was at, when I started there, they were using a MySQL database as their warehouse. And it was exactly that. I would run a query, and I want to be outside of the range of expectation that it takes 45 minutes for that query to come back to me. And then I'm pretty sure they just had all their settings to negative one, or zero, or whatever, so there was no timeouts going on on those databases.

But they were also insanely easy to bring down. I had released code there, and for some reason, they were running a five-server leader configuration, which just didn't work at all. I did a code release there, probably my first one that just took down all five of those.

MIKE: Oh.

ZACK: Because you had to just write your SQL so perfectly to pull the data outside of those types of databases. And even then, like I said, you're waiting 45 minutes. And that's just the most inefficient way. I'm sitting there for 45 minutes, not able to continue developing my script because I'm just waiting on data to return to me.

MIKE: Going back to what Jason was saying before about the freedom to experiment, you have very limited freedom to experiment in that kind of environment. And that data warehouse gives you the power, the ability to experiment, again, takes the shackles off. Now you're free to go try stuff.

ZACK: Exactly, yeah.

MIKE: It's interesting that SQL and data warehouse came up as a vital tool. Do you have anything else that you'd bring up from the data side, or do you think you've covered the key items, Zack?

ZACK: I think that I've made the key items. I mean, you're familiar with Dave. He ran the show last week. He also develops inside of the terminal, like you guys were talking about. I would mention that I did end up inside of an IDE. I used to use VS Code. I ended up inside of an IDE, specifically JetBrains, because I started delving in Scala. That all has to compile at runtime. It was so much easier just to press the play button in an IDE than doing anything inside of a terminal.

So you guys were discussing how the terminal is extremely powerful and faster to use in that way, and I don't disagree like 90% of the time. But I do believe there's that 10% of the time where having [laughs] a UI tooling is just remarkable. Like, I dev Android apps, and I wouldn't want to do that without Android Studio spinning up an emulator for me to work on.

MIKE: That makes sense. And when I was a full-time Java developer, I used the JetBrains suite as well, IntelliJ, all the way. It's an amazing tool.

ZACK: It's funny; I really tried to use the terminal. And I was just getting these weird errors in Scala just because it wasn't compile...I was trying to not compile. I was trying to run a scripting language, just read it out and run it instead of compile it down to bytes and run it that way. And as soon as I jumped into IntelliJ and pressed that play button, it all just ran and worked but could not get it to work inside [laughs] of the terminal.

MIKE: It's not that that's an insurmountable problem but, like you say, the ease of use. I'd actually recommend that most new developers use an IDE, use an integrated development environment, a big graphical editor that lets you see things because it's a lower bar to entry. Why not use a powerful tool that makes it easier for you? But learn the command line too. Treat that as a goal. While you've done the easier thing, try using some of the command-line tools. Try experimenting with them here and there over time.

ZACK: I agree with that as well. I spend a lot of time in the command line. And I spent a lot of time early on through college working in networking and setting up headless machines that you just had to SSH into so there was no GUI that you could work with. And through that time, the three big ones that I would say if you know these, you can do just about anything would be Grep, as we discussed, sed, and awk.

MIKE: I use sed a lot. I need to use awk more. It's also a remarkably capable tool.

ZACK: Yeah. And that's one that I never really use a lot, either. [laughter] I never really hit cases where grep, and sed just didn't work for me.

MIKE: Exactly.

ZACK: And on the rare occasions I did, it was just like, I'd Google to figure out what command it is, and it was [laughter] typically awk.

MIKE: That's pretty much where I'm at. [laughs] Grep and sed encompass almost everything. And then awk, you know, that's what Google is for. [laughs]

We're reaching the end of our scheduled time, but to go back and summarize, we've talked about some powerful tools over on the data side, specifically, data warehouse using SQL or SQL, whichever you prefer, you want to call it. We've talked about command-line tools, particularly grep. And we talked about the value of version control system. We talked about Git and the value of IDEs. And the commercial product from the JetBrains suite of commercial products are really very good tools, as well as VS Code, which has become very widespread within the industry.

Hopefully, if you're listening, you've got some great ideas of things you might want to try. Is there anybody else who wants to put in a plug for a tool that we haven't covered or talk about some concepts we touched on, and you really want to dig in a little further?

KYLE: I realized when Zack was going over tooling that they use in data, I didn't really talk about some of the major ones we use in DevOps, which is I would throw out TerraForm, Kubernetes. Those tools specifically because...TerraForm is how we manage all of our clusters and all of our infrastructure out in AWS and Google and wherever that's managed.

ZACK: Just another one, real fast; Kyle reminded me when he brought up Kubernetes is we have started using a tool called Argo. It's a workflow management tool: also extremely important. In your normal software and engineering environment, you have typically something that happens that causes an event stream that runs through and kicks off whatever endpoints or whatever needs to be kicked off. A lot of times, with data, you just have to schedule that. So we use Crontab as well as Argo to schedule our jobs to run.

MIKE: Cool.

KYLE: Last plug, Docker. Docker has to be mentioned.

MIKE: Yes. [laughs]

JASON: The debate rages on.

MIKE: [laughs]

MARK: In Docker's favor.

[laughter]

MIKE: So I'll hopefully tone down some of that debate by saying that Docker is widely used in production and even on production deployments. In cloud deployments, having containerized code is just incredibly useful. For local development, I think there's a lot more debate as to whether you just want to run bare metal or whether you want to run containerized. Is that what you're touching on, Jason?

JASON: Yeah, just locally, obviously, it's resource-heavy, but I absolutely see the kind of the compartmentalization; like you said, the whole point is to run in containers. I can see where in a production environment, that's extremely useful. But yeah, there's been a lot of debate here at Acima over whether Docker is...if we should rely on that for local development, just the memory requirements, basically.

MIKE: You know, interestingly, we do rely on Docker, many of us, for local development, even if we're not thinking about it because we'll connect to cloud instances for some of our services, which are built using Docker.

ZACK: I was going to say my argument for running Docker locally, at least from what I've found, is it only uses the resources that are needed for that, which for my team is really easy because it's only using resources if we're running a script. As well as it's been extremely helpful to have a development environment that is pretty much a one-to-one to production. You don't get any of the sneaky, like, oh, it's failing in production, and I have no idea why it's going on. It will fail on your local machine if it's going to fail in production.

MIKE: It's wonderful to be able to compare.

KYLE: I think that is one benefit with Docker that is a little bit overlooked is we get this response from devs sometimes, you know when something is deployed, and it's...well, it worked on my machine. Well, that's great, but we can't put your machine in AWS. However, if you give us a Docker image, we can put that in AWS, and that's the same image that will be running on your machine as will be running on a machine out in AWS.

MIKE: That's a big deal, that consistency.

ZACK: If you look at toolings before Docker, it's not a new idea of trying to match local to production environments. Before that, there was Vagrant, which admittedly was maybe a little bit of a shit show; hard to manage but definitely been going for that for a long time. And I think Docker kind of hit the nail on the head with it.

MIKE: It's becoming remarkably successful and integral to a lot of what we do for a reason. It kind of takes the virtualization idea to its logical extreme. Let's strip out everything extraneous and have just what we need but everything that we need. All of your system libraries and your application that depend on them; we'll put that in a bundle and nothing else. It's a powerful, powerful way to approach deployment and even local development to get that consistency.

MARK: Docker has also been great for privacy and so forth. I know recently I discovered that you can run full-blown browsers within Docker and then access those browsers from your other browser. So I can have, say, 30 Firefox containers in Docker and have each container for a specific reason. So instead of creating profiles on my main computer for everything I want, I could have containerized Firefox applications for what websites I go to, which I believe is a great plus for security and not just development means.

MIKE: Yeah, if nothing else, you can segregate home from work. [laughs]

KYLE: I will say one thing that I've found developing in Docker is I tend to really kind of mess my machine up, and a local machine that requires a lot of debugging and figuring out what have you done and backtracking. The Docker image, use it, abuse it, throw it away, start up a new image.

JASON: I think that's a huge selling point for me going back to what we were talking about before with the freedom to experiment. I think that's pretty powerful.

MIKE: Well, it sounds like a good place to tie this up. There are a variety of tools that give you that power to experiment, and they've been coming up repeatedly. Docker and Git were mentioned particularly in that regard of the data warehouse. Anything that allows you to try something without breaking things is going to make your workflow much more powerful.

Thank you for joining us today. And, hopefully, we gave you some ideas for things that you can go use yourself. And I don't know if we'll be seeing you, but you'll be hearing us next time on the Acima Development Podcast. Thank you.