Acima Development

Panelists discuss testing with RSpec, focusing on issues like mixed idioms and non-idiomatic code. They explore the importance of following the framework's conventions and using easily understood exemplary data. The concept of cognitive load is introduced, likening it to Newton's law of gravity applied to code, and they emphasize locality and scope in defining variables.

The conversation also delves into potential disagreements regarding overriding values with "let," but they find common ground! They advocate for defining variables as locally as possible and avoiding unnecessary complexity. The balance between readability and idiomatic practices is explored, with both agreeing that meaningful setup should be placed at the minimum distance necessary.

In closing, Dave teases a future topic about the difference between duplication and repetition, challenging the conventional wisdom of DRY (Don't Repeat Yourself) in unit tests. Stay tuned for Part II!

Transcript:

MIKE: Hello, and welcome to another episode of the Acima Development Podcast. We've got kind of a big crew here today, where it's myself, Mike, who will be hosting today. We've also got Ramses, Dave, Eddy, Justin, Sergio, and Freedom [SP] with us today.

We are going to be talking about unit testing. Very specifically, let me give a little context here. I want to approach this in kind of two ways. We're going to be talking about a specific unit test framework that we use a lot in Ruby called RSpec. Yeah, even if you're not a Rubyist [laughs], even if you don't use this tool, I think a lot of what we talk about will be applicable outside of this specific framework that we're going to be talking about.

But there are a lot of people who, particularly getting started with RSpec, what is going on here? If you're that person, listen on. We'll be talking about that. If you're not that person, again, I think that a lot of what we'll be talking about are kind of general principles that apply to unit testing, regardless of framework.

I'm going to talk a little, lead out a little bit here, to kind of start the discussion talking about RSpec. I'd say that most people who first look at it kind of scratch their heads a little bit. And, like, well, I think I know what's going on here. And it will copy another file and then just tweak it, which usually works pretty well. The problem with that is you end up with kind of these lineages of copied code [laughs] that diverge from each other and kind of naturally evolve over time and diverge from each other in ways that are sometimes unhealthy.

Sometimes, you end up with something introduced in there that really shouldn't have been in there that was either meaningless or problematic and ends up kind of poisoning the descendants of that file as they get copied over and over again. I'm talking about RSpec. This is true of code in general if people kind of start with a template and copy it over. That happens especially in unit tests because your test has some boilerplate to approach the problem of, you know, validating code.

You know, at some point, you have to have some sort of assertions. You know, you have to test some logic that happened. And it's more likely to be copied, you know, to be coded by copy, and then code in other places. Because in other places, you might be starting, like, well, I'm going to approach a new problem. There is some degree of copying that goes on there.

But here, it's especially tempting to just copy something wholesale and make some minor tweaks. Because you're like, well, yeah, well, I'm just testing this slightly different logic here that was similar to something over there. And I don't do this as much as I write code. Maybe, you know, maybe your company hasn't done much unit testing yet. And so, you know, I'm not as familiar with it. I'm just going to start from that.

And I've seen many times this divergence of testing as it goes through this copying lineage and ends up evolving over time. And you can even, like, kind of identify when the tests were written because, like, oh yeah, this was vintage, you know, 2018. And I think we can do better than that. We can do better. As an industry and a whole, we can do better with RSpec because it's actually a really great tool that I love. It took me a while to get my head wrapped around what's going on. I think it's because it's simpler than I expected.

And I'm going to start by making a few assertions from my experience. And I say it's assertions. I think that's fair. I'm going to say that we should go about this problem in this way. And that will prompt some rejection of my assertions from our panel here or allow us to dig deeper into how some of those apply.

Here's what I'm going to start with. I'm going to talk about this. Again, we're talking about RSpec, very specifically. RSpec is written in Ruby and really takes advantage of a feature of Ruby that's called blocks. For those who are not Rubyists, they're just a little special syntax for anonymous functions. Ruby is really based around that. And RSpec is designed to create specifications. So, when you run it, it's not strictly unit testing. It also produces documentation of your code. You're specifying what your code should do.

And well-written RSpec will read like documentation, so you can use it to look and generate documentation for your code and understand what it's doing. And it does that by using the rules of context in the language. What is the variable scope here in these blocks? And that's not something that we always are really good at thinking about. But if you think about what's really going on there, is it's just passing around some functions. It registers something somewhere. I haven't even dug into the code that much. But it's taking these anonymous functions that you pass into the specifications and registering them so that it can execute them later with some documentation, so it prints them out.

So, you think, well, I'm just going to create some code that it'll run at some time. At some point, it'll register it. It'll run it, and it's going to run it with some documentation. And if we start with that mindset, that doesn't sound too bad. Like, oh, I've just got some code that can run and print out some documentation as it does that.

And the second thing that I want to say...so I want to start by saying, well, Ruby allows you to do this, you know, it's going to create these anonymous functions, and it's going to run those. And if we remember all these dos and ends, and blocks that are going on and all this nested structure, it's really just nested calls to this anonymous function. Well, I think I can wrap my head around that. I've just got a piece of functionality that I'm going to call later.

Other thing that I want to say is that what we're doing when writing to unit test is actually relatively straightforward. And it is taking our code and identifying the branches in that code, the logical branches. Now, these may be explicit. You might have an if...else. Well, that's obviously a branch. But you may have something a little bit more subtle, where you have a return statement that happens sometimes, or you have an exception that gets raised that causes your code to branch in ways that aren't as explicit but are still happening.

And I'm going to argue that what a unit test is there to do is to test each branch of your code. And if you think about it that way, what I want to do is I just want to exercise each branch of my code; well, then the challenge you have with testing is not to try to think of every scenario but rather to just simply destructure your code into its branches and follow each one of them. And my experience has been that that approach to using RSpec, and this applies, again, not just to RSpec but unit testing in general, is extremely effective.

It leads to very clear, legible tests that print out good documentation and actually capture what we're trying to accomplish, which is we want to make sure our code does what we thought it did. And what code does is it takes a certain set of scenarios and executes on them. And if we test each branch, well, under this condition, it does this, then we've covered everything in a way that we can think about.

RSpec gives us context to represent each of those branches. And so, if we use context in that manner to represent one of those branches, then we will just have a set of nested context that follows our branches down. I think that a test that is built that way works out great.

If you're using more features of RSpec than that, you might start running into trouble. If you start trying to use something really esoteric or sophisticated, you might actually hurt yourself because you are trying to oversimplify or overcomplicate, as the case might be. But you'll make your code less hard to see at any location in your code what's going on. We can get into that later.

I'm going to start with my high-level assertions. Dave, who's here, has actually given a conference talk before on this topic. I expect him to have some feedback. I'm looking forward to the feedback. We've also got Justin here, who is not very familiar with RSpec, and I want him to pepper me with questions because you're not very familiar with RSpec, but you've worked with other testing frameworks. What are your responses to what I've said so far?

JUSTIN: Sometimes, it's hard to look into it without comparing it to other ones, right? I'm looking at it from a perspective of JUnit tests from the Java world that I came in. I don't know if we want to go into that yet, like comparing directly. But that's the way I would look at it was, like, okay, how easy is it to mock? Is it as easy as Mockito or other mock frameworks that I've used? You know, is the response formatted well? Does it work with all my CI/CD tools? You know, all those sorts of things are very important to me.

I like the fact that you can look at it and read it. That's really key to me also. Even though if you aren't familiar with it, you can read it like English and see, oh okay, this is what we're testing. We're testing this specific path in my code. And I can tell that just from reading the thing.

And then finally, is, how fast can I pop these out? Like, I want to test all the branches, just to make sure that everything is correct. And the other day, when we were chatting for the book club, I thought that was excellent for me looking at those examples. But yeah, I just wanted to kind of dive deeper into those things.

MIKE: Great. You hit something important there. You know, and I used JUnit as well years past. A lot of this is tool-independent. You also pointed out something interesting about the legibility. Again, RSpec...it's right there in the name, your specification. By kind of flipping the way you think about the problem from, well, what are my list of assertions? To saying, well, what am I specifying here? What am I documenting? You end up with tests that read a little differently.

Instead of thinking about the problem in terms of a list of assertions, you can think about the problem in terms of those logical branches and have the specifications read that way. And I think that that is actually a big deal. And the people who've embraced it, I think, really love the tool, really love RSpec for that reason. It's because it maps very naturally to healthy tests that generate this kind of good documentation.

But if you're trying to think about it as list of assertions, which is kind of a natural way to think about things—it's often done that way—you can end up in kind of a weird mental spot where it's hard to think about the problem, and you end up with a test that's somewhere in between that is maybe not as healthy as it could be.

DAVE: What Mike said about the concepts are similar; this is going to sound like a comment from The Matrix. I don't see the code anymore. I just see block context expectation. But you can see this in any language. Like, in JavaScript, there's a testing library called Jasmine that is literally a port of RSpec. You can tell that whoever wrote this went, RSpec has a really cool concept. I'm going to steal it.

And then, there's another testing gem in Ruby (It's actually not even a gem. It's in Ruby Core now.) called Minitest. It is RSpec with all the magic stripped away. It's literally just define a function and run the thing. And when you're like, oh, well, how do I do a context? And then, Minitest is just like, just write a function. Well, how do I let a variable? Just write a function. In RSpec, we can say things like, let database, and then you give it a tiny block that says, you know, Postgres adapter dot new, username, password, database name, right? And that's all it is.

And you're like, well, how do I let the database in Minitest? Well, you just write def database, Postgres connection, new username thing. Although later on the call, yeah, I'm probably going to argue for…you could probably just put Postgres adapter dot new, username, password, database in every single test, probably, maybe not. You know, you might not want that. But depending on some of the context, if that's an important part of the detail, you should put that in every test.

But the idea is the same across the board. Like, if you go look at Jasmine, there's a function called describe and a function called it, and they're the same thing. They take a string describing the thing you want to test. And then, they take an anonymous function in JavaScript. That's your Ruby block. And inside of it, you can write an expectation. And that's the entire Jasmine library. It's just describe, it, and expect, which is really kind of cool.

Another common parallel is, like, I've seen people that will organize their test suite where they will make a subdirectory for each object that they want to test. And then, in that subdirectory, they'll describe a condition as another subdirectory. So, you might have a database connector. It might be literally a subdirectory in your testing directory. And then, you might say, like, anonymous users or unauthorized users might be your next directory.

And then, you could have five different file names that describe a different case or a different branch of how things go down in that context. And then, you open up the test file, and there's only, like, two methods in it. And you're like, this is really tiny and, like, that's pretty spread out. Similarly, you might have an RSpec file that has that entire directory tree all in one file because it's just context. You know, describe the database, context when the user is anonymous, context when the user is illegal. And then, there's all the things.

And so, you might have, you know, a 2,500-line RSpec file that describes what the other test library did with, you know, a whole fleet of test files. But it's the same idea. We're describing things. We're grouping up collections of behavior. And then, we are describing, or asserting, or specifying, or testing and expecting that it's going to do something.

MIKE: The thing that you mentioned, repeating the setup, I think that that's something that we should really dig into. There's a tricky balance there. And there's a style that I've come to favor, and I'm going to say why I favor it. But there are some constraints to that.

DAVE: There's a lovely catchphrase that I came up with. I have refined that catchphrase because I found it unsatisfying eventually. I want to hear your thing because I'm betting that you ran into the same unsatisfying thing that I did. And I'm hoping that you came up with a completely different and interesting approach to it because then I will learn a very cool thing. But I have refined that idea a little bit, but I want to hear yours.

MIKE: Okay, here's what I'll start with: I think that if your setup is not in the same file, that makes it hard to find, and you've done something wrong. Every rule, in general, has an exception. And so, I'm sure there are exceptions to this. But as a general rule, I'm going to argue that the file level is an excellent place to localize or to don't repeat yourself, you know, to DRY things up. And all of your setup should be within the same file.

Now, other people might have some style difference. And they say, well, maybe it should be within a certain describe block within the test for a single method or something similar. Those are little nuances. And they may actually are not even in disagreement because they probably won't have much overlap between method tests.

There is a real problem, and I think that's what you were alluding to Dave, is that if you have setups somewhere far from where you're at, it makes it really hard to work with your test because now you have something shared with something else. And they're going to fight with each other [laughs], and not only fight with each other but be far away. And you have to go dig around somewhere else to find it and hope that if you change that setup, that you're not breaking everybody else's stuff.

DAVE: Yes.

MIKE: And that's terrible. So, here's what I like to do. I like to set up a happy path as default configuration. In RSpec, I would do this with let blocks, which, again, allows you to define a little, anonymous function that will just define essentially, like, a variable. Think about it like a variable, but it'll be executed a little bit different scope and has some caching associated with it. I like to do all of my setup for a happy path.

In my context, I don't respecify the happy path information; rather, I specify what is unique to that context. So, for example, somebody forgot to pass in a username context. I would override my happy path username with a nil username. Then, within that context, my only setup is going to be, well, let username be nil because that's how it differs from the happy path.

And then, it's very obvious, within that context, what that context is testing that's different from the default case. It allows then my assertions. In RSpec, the specification syntax is really nice. It's the function called it. So, you can read it as it should work, or it should raise an exception, which reads, again, really nicely like English. But it allows my context to be a little more than the specification of what it diverges from the happy path. And my assertion means it's really easy to tell what's going on.

If I want to go see all of my default setup, well, I just scroll up to the top of the file or to the top of the block for the function I'm describing. So, it's really easy because I know that all of the happy path setup is at the top of...just scroll the top of what I'm testing. It's not far; it's easy to find. And it's all...by default, it's going to show everything as it should be.

And then, in my context, we'll talk about, you know, all these branches. And a lot of times, you're branching is around validation and unhappy paths. And then, down at kind of the bottom level, I'm going to go into deeper and deeper nesting of, you know, this thing was wrong. This thing was right. And as I go all the way down, I'm going to remove some of these bad conditions and end up with something that just works. And that means that at any level, I'm only specifying what differs from everything else.

So I don't have to think about other setup. I'm trying to accomplish the thing you're talking about is, like, I don't want to have to go somewhere else to find what I need to think about. And I think that I can accomplish that by, again, setting up the happy path by default and each context showing something that's different. That isn't the only way to do it.

The tests that I've seen that follow this pattern, and I've seen other people follow this pattern, it's generally very well received. People say, "Wow, this is so easy to read." Again, this is not unique to me. I think it's how the framework is designed is to allow you to, you know, to specify the specifics in your context that make it specific.

DAVE: I like all of that.

EDDY: So, RSpec is still relatively new to me. Like, I've started to really get into it pretty heavily. And the thing is, is, like, when doing a bunch of research, you stick to what you know, right? Or what the codebase is doing. But then you look up other implementations online, and suddenly, you have different opinions on, like, the best way to write it, right?

For example, you mentioned that you like to set up your test with let, right? But there's something to be said about avoiding RSpec constructs like let and before and, like, sticking to plain, old, like Ruby methods and variables. So, there's something to be said about that. People argue that it even reads better, right? Since you're not applying, like, a different implementation, if that makes sense. Because on the surface, it's still Ruby.

MIKE: Well, I would maybe have a simple counterargument to that, which is, well, you could use Minitest [laughs], right? To some degree, I think it makes sense to...and I don't think this is always true because you could use obscure features of a framework that are probably going to [inaudible 18:25] anyway. And that's probably a bad idea. But I think it generally makes sense to follow the idioms of the tool that you're using. And don't try to force another idiom onto it.

If you want to go leaner than what RSpec has, to Dave's point, why not use Minitest and just use the functions all the way down and not worry about the framework? I think that that probably would make more sense. Let's not bend RSpec into something it isn't. Let's just use the tool that we've got if that's the tool that you're using.

DAVE: I have a statement that describes both of your situations as a single statement, which makes me very, very happy when I run across this. This is something that I learned from another panelist on Ruby Rogues. When somebody says this is readable, what they think they're saying is they think they're making an objective statement about readability, like, there's some quantifiable what is the readability of this passage of code? 4.12. What does that mean, right? 4.12 of what? 4.12 readability, obviously. It's what I just said.

MIKE: [laughs]

DAVE: Right? When we say this is more readable, what we really mean is this is similar to what I am familiar with. A lot of people coming from plain, old Ruby and Minitest they expect functions, right? You are in a class, and you are in a function. People who've really been soaking in RSpec, here's a thing that might kind of bake your muffin just a little tiny bit.

In RSpec, we say, you know, describe thing do, and then you're in this block, right? And we know what a block is. It's an anonymous function. No, it's not. It's a class. What? Yeah, in RSpec, we turn blocks into classes, and they all inherit from—I'm going to mess this up—like the example class, or something like that, or the context class. Don't quote me on that. I haven't looked at RSpec code in a year.

But it's a class, which means you can do something in RSpec blocks that you can't do in plain, old Ruby, and that is define a block. And then, in the middle of that block, just declare a function. Like, literally just describe database do def connection. What? You can have do and then follow it with def. You can't do that in plain, old Ruby. But in RSpec, it magically yields this anonymous class describing that test case, which now we're in this really dark, Byzantine black magic of RSpec.

There's people that, like, prefer Minitest. I don't know if this is still the case, but the source code to Minitest used to be printable on two pages. And the source code for RSpec was a document about this high, which can make it hard to wrap your head around what is the test framework doing? The reason I love RSpec is because I don't need to know what the framework is doing. Describe thing do. In my do, I'm going to use lets and its and contexts, and that's all I need. But yeah, sometimes you're like, hey, I want to describe this.

So, when we say readable, what we mean is what is familiar to me. The active bit to this that I would suggest is to recognize that if you come across something that is not readable or not familiar to you, take a moment and step back and go, is this person really just kind of clumsily mixing unimportant details with important details? Or is this person transmuting concepts into their local idiom, like the idioms or the framework? Have they translated this into this foreign language, right? So, it's not my native language, but they've translated it to this foreign language.

Oh, they have translated all of the important things of this, and they have left out all of the unimportant details? That is probably an indicator that you should bump up your style. You should sit down and go; I'm going to learn the style here. It's not readable to me. It's not familiar. But I'm going to study it until it becomes something that I'm fluent in.

But on the other hand, if somebody is yielding a block and just slapping a method in there because they don't want to use a let, even though a let really is just another anonymous function that's lazily evaluated, that's all it adds to is, if you don't call the function, it never gets evaluated on that test run. RSpec just does that for you.

If you want to get away from that overhead, yeah, jam in a def, but recognize that the people on your team that are RSpec...oh, and this is the dark side of that, which is that if you walk into a document written in French and you're like, I don't speak French, but I speak English really well, and you jam in a phrase in English, recognize that everyone else on your team might be fluent in the French, and see your English and go, "Oh, you've just pushed a really painful bit of cognitive load."

What they will say is...they won't say you've pushed a bunch of cognitive load on the rest of the team. They'll come back, and they'll go, "This isn't very readable." Oh, hoist upon our own petard.

MIKE: I think you nailed it and very consistent with what I was saying. We mix idioms; it makes it harder. And most of the time, when I've seen RSpec that is hard to work with, it has been because of those mixed idioms. It has not followed the RSpec idiom. I didn't understand it. But it was saying, well, I'm going to try to do things my own way because this is what I'm familiar with.

For example, I've seen a lot of setup that will define a before block, which is, you know, kind of some setup. It's going to be open and, hey, do this before all the tests. And they'll just define a bunch of instance variables within the class so that they're within the object that's going to be created that then can be used later. Well, yeah, you can do that. But once you've done that, it really doesn't look like RSpec anymore. You've basically just written your own test framework [laughs], and it doesn't follow the conventions of the framework we're using. And it forces everybody to bend around it.

And that happens; I don't think deliberately. People just think, well, I think I've seen something like this; let me try that. And not thinking about the fact, well, this really is just a set of anonymous functions. And if I'm doing it differently, I'm probably doing something wrong.

DAVE: That's really well said. So, winding back a little bit, I said that I had refined this idea a little bit. And then, you actually gave a different angle to it, which excites me because that's what I was hoping was a different viewpoint of this.

The thing that you talked about if, like, something is in another file, it's more painful. And what I've come up with is kind of Newton's law of gravity but for cognitive load. And cognitive load is the mass of what you're testing times the mass of the thing that you are including divided by the square of the distance between them. Okay, that's fun and fancy and math nerdy. Here's what I mean: if you are in an it, like, when I do 40 plus 2, it should be 42, or I expect it to be 42. In my it test, if I say A equals 40, B equals 2, expect A plus B to equal 42, it's all right there.

I might say, let A 40, let B 2, and I might stick that up at the top of the file. That's a little more distance. There's a little bit of cognitive load there. And there's an important reason why you should use that. But if you use it because you're just used to putting all your local variables in let, please stop because you are paying a price to put that variable into orbit, far away from your code, not far away but farther away from your code.

And if you move it to another file in the test suite, that's even farther. And if you move it into another piece of code in another gem in a different repo, forget about it. Why are you testing that? Leave it alone. Get away from it. Here's the value to this. And I'm going to switch to a litmus rubric kind of thing. Ask yourself this question...and it makes the answer feel a lot more intuitive to me. Take what you're describing and the context, right? Describing the database when an unauthorized user attempts to log in. Take that.

And now, in your head, imagine the Stack Overflow question: Hey, what happens when an authorized user tries to log into the database? Now, what goes in your test is the snippet of code you would put in the Stack Overflow answer. Now, think about that. If you say unauthorized user connecting to the database, and if this is on a Postgres forum, I'm probably going to say, Postgres adapter dot new, dot username, password, database. Because anybody just reading this webpage needs to know what kind of database class are we using? Are we using the ODBC class? Are we using the Postgres? Are we using the Pg gem? You need to show that. That's important.

And you might sit there and go; every single test on the database has got to connect to this database adapter. Yes, because somebody who comes to Stack Overflow doesn't care about the 23 other things that you are testing. They should care about the one thing that doesn't work. The old rubric I used to use was tell the whole story, and it made it really easy to put duplication into your code or to get repetitive needlessly.

So, you're going to say Postgres adapter new, username, password because somebody reading this is going to want to know where did this connector come from and what flavor is it? And then, you can have your assertion. If something is relevant to the way the test runs, and in RSpec, we might do this with a context, I will put those in a shared bit of code in the same file, like a before block or a let statement. I won't ever use a shared context, but I don't want to talk religion. That's just me being religious.

The idea...so, you've got somebody coming in, and they're like, what happens if we try to log in the database when some other thing, you know when we have seven-bit arithmetic turned off? Which, why does that matter? I don't know. There's some weird detail. The eight-bit versus seven-bit arithmetic it's important.

So, okay, it's not super important to this exact test. But you're not going to be able to sit down with a blank install of Ruby and get this test to work. You're going to need this. And you can pull that out of the test, but remember everything you pull out of the test. Imagine somebody sitting next to you reading your Stack Overflow question, and they go, "Hey, what's this?" And they point at that variable.

If it's something that you go, "Oh, it's this. Oh, it's the arithmetic base," "Oh, okay, got it." That could be in the same file. We're going to put it into orbit around this test, but low orbit, right? We're going to put it in the same file or maybe in a before block of this context, right? So, it's only up, you know, 15 lines from this bit of code. But if it's something that somebody goes, "What is this?" And you go, "Ugh, I don't even want to talk to you about that," that shouldn't be in the file. That could go away. That is something you should pull out of this thing and move it very, very far away.

You sit down, and you say, Postgres connection, blah. And then you do, like, you know, Devise or Warden login. And somebody goes, "What's this Devise thing?" "Dude, Devise is a whole Ruby gem. It's part of your system. It was part of your application setup. I don't want to get into that." If that's not working, we need to have a completely different conversation. And that might be what's broken. That might be why you came to Stack Overflow.

So, I'm going to give you just enough of a hint, which is I'm going to use this thing, but I'm not going to tell you what it is. And when you go looking for it, it's very far away. When you go far away, you start to drop context out of your brain because the cognitive load gets heavier and heavier and heavier. I argue that it increases with the square of the distance. The further away it is, the more and more and more it gets harder to hold in your brain.

If you get out two files and into another gem, you're not going to remember what you came to this little test Stack Overflow answer, right? This little test answer that you got. You're no longer talking about that. And that's good if that is what you want it to make happen to the reader. Devise is broken? We need to have a different conversation. The problem you think you're having, which is this user is logging in weirdly, no, no, we need to have a different conversation. Your Warden setup is completely broken. That's the thing that you push far away.

You need to have Ruby compiled for ARM versus Intel. That's a completely different conversation. But think about it: you need to have that before that test will pass. But that shouldn't be in this test. It's not relevant to this test. Make it far away, very, very far away, right? Literally, RSpec at a [inaudible 30:06] and you hit Enter, that should not work if your ARM versus Intel is broken, and it won't, which is great. Don't drag that into every test. Don't say, yeah, compiler settings set to..., right? It's distracting.

MIKE: I think you hit on something that I'd like to build on a little bit. You talked about some things should be far away. And it comes back to what I was mentioning kind of briefly near the beginning, which is about variable scope. I think the setup should be scoped at the minimum distance that it can be and still work. I think --

DAVE: At the minimum? Everything would be in the block, in the it block, right?

MIKE: That's interesting. And I think that the answer is no. Because if --

DAVE: Ooh, some things should be far away. Sorry, sorry, I think I just picked up your breadcrumb. Go ahead.

MIKE: If you put everything minimally far away so that you don't have to repeat ugly setup, right? A setup that is hard. Now, easy setup, something that's trivially easy to set up, like, let's say, well, I want every usage of the integer one to be shared across my whole app, and so I'm going to set up a global constant of one. So, if anybody wants to use the number one, they should use that constant. Well, that is abuse of the system. That was set up that was trivial, and you're actually making things worse by making it universal.

DAVE: Because it has nothing to do with the database login.

MIKE: It doesn't. So that meaningful, the meaningful setup, meaningful setup should correspond to its scope. And so, for example, in your example of properly configuring your database connection, that's global, probably, global for your application. And so, that should be configured at a global level. If you have, within a context, something that's going to be used in multiple different tests, then it should be defined within the scope of your context. It should be in a let block at the top of your context.

If you have something that's only going to be used within a single it block or a single block that's going to have some assertions, then that should just be in a variable defined within there because it's not going to be used anywhere else and just particularly if it wouldn't be used anywhere else. If something is obviously going to be nice to read, if you're going to be writing another test in five minutes and you're going to be reusing it, well, be nice to yourself and set it up.

But this idea of locality and of scope, I think, is vital, and it's related to scoping our variables, generally. But, you know, global scope is generally dangerous. But there are some things that should be global. And here, I think the same thing applies. In general, most things should be as local, you know, be quite local because they're only happening locally. But if you have something that's going to happen within the context, well, it should be in the context.

And if you have a wrapping context where it applies, well, define it there and define it in RSpec in a let block so that you can override the value. Here's an example: if I have a list of parameters that's going to be passed into something, you know, something that has got named parameters, say, and I've got a list of five named parameters, well, there's some setup involved in calling the constructor, right? You got to call the constructor with this set of five parameters.

And if I repeat that everywhere in the file, it's a lot of visual noise. There's some overhead that I'm going to have to fight with to say, okay, I have to dig through all of that setup in every test. So, I think it makes sense to use RSpec's feature for that, which is subject. And I could define my subject with, you know, I'm going to instantiate this class, and then maybe within my particular describe class, I'm going to call methods on it, but I'm going to do that instantiation elsewhere. But I'm going to have a let block for each of those parameter values so that if I need to change the parameters, I can easily override it anywhere.

Now, there's a place where I think that having some shared code actually makes it easier to read because I've removed visual noise. And the scope that that's in is within the scope of, well, it's really my unit test, right? Because I'm testing this shared within the class or maybe shared within the method. That is shared scope. They're using a shared thing. And that way, I only have to override what's not shared. But if there's something that's really only going to be used locally, well, yeah, it should be defined as a local variable because it doesn't apply anywhere else.

DAVE: I like that. There's a thing that you were saying that was kind of putting my hackles up. And then, I think we're actually mostly, mostly on the same page.

MIKE: [laughs]

DAVE: And that is, there's this notion of using exemplary data. Now, this is…we talked before the call about artistic versus implementation grindy details, right? That's like, Minitest, you have to write def thing. And RSpec you have to write it do. That's not art. But then you get into, what are some artistic things? These are things that could be done either way. It compiles just the same. And different people find it appealing. And exemplary data is one of these things, and I really like this.

So, let's say we've got some custom integer class, and it needs to do addition. Or, no, actually, we've got an accounting class that is going to add these things up. We don't actually care how it's doing the addition. We just care that the addition is correct. And this is the thing that I used in my talk where I said I would not use let A be 5, let B be 7, expect A plus B, and then let answer be 12. And then, expect A plus B equals C. I would never do that. And the reason why is because I have had cases where A and B were both nil, and this did not throw a nil value exception. And C was also nil.

And I'm looking at this test seeing, oh, A plus B equals C. Okay, cool, cool, cool, cool. No, your whole system is broken, and your test isn't telling you that. But if I give you a piece of code that says expect to be adding function on 5 and 7 to equal 12, you don't have to look at anything else. You immediately know. And part of this is because we all just look at 5 and 7, and we instantly know what that means. And we know those added together those are 12. Perfect. That's great. We don't have to stop and look at what it is.

A little slightly higher level, let's say you've got a user who can log into the system and a user who can't. And we're, like, showing the differences in the behavior. When you try to access your change password page, you should get, like, a 403 forbidden, right? You should be sent to the login page, not to the thing, right?

I would not do, let good user be this user; let bad user be this user. I would actually have let. I have an interloper. It wouldn't even be a let. I would have a local variable. I have an interloper, equals user dot Ivan, bad person, password illegal. And then, next line, good user equals Alice Johnson, password, you know, let me in. And then, in the test, we see Ivan cannot do this, but Alice can. Or when Alice tries to access this page, she gets this page. When Ivan tries to access this page, he gets that page. And I love that. That's this beautiful deterministic.

When the interloper comes in tries to access this page, he gets sent here. And that is correct behavior. In the same way that if you say I write a divide function and you try to divide ten by 0, the correct behavior is to burn down and sink into the swamp, right? The correct behavior is to raise a divide by zero exception. Somebody once expressed this to me visually. They had just bought a hybrid electric car. And there was this gray, big, like, six inches on the side yellow warning of a stick figure being struck by a lightning bolt while trying to put their hand inside the battery compartment. This is a pretty clear message.

But he described it in terms of an RSpec expectation. He said, if you stick your hand inside this box, you must electrocute yourself to death with 30,000 volts. And I'm like, what? The correct behavior is be electrocuted to death. Sorry, that's kind of weird content warning, but anyway. The correct behavior is to burn down, fall over, and sink into the swamp. So, specify that, right? --

MIKE: Well, what you're saying is actually very much in line with what I was saying. You're talking about the exemplary data. As I was suggesting at the beginning, in my tests, I like to define a good set of data as the default. Here's a good example. And then, my context should break that data and should be saying, this is how it's wrong, context that A, B nil, right?

DAVE: Yeah.

MIKE: And then, my assertion is going to say, it should, you know, raise an exception of whatever sort it is. That should be abundantly clear. I want my test to illustrate what happens in this scenario. In this context, when we follow this branch of code because that's a branch of code, too, right?

DAVE: Mm-hmm.

MIKE: Divide by zero; well, this should happen. Not an obvious one. You don't have an if block there, but you certainly have that branch. I want to cover each of those branches. And I want my test to be structured that way. And I like my setup to default...my setup right at the beginning to default to, you know, the happy path. Everything's good. And then, have also the tests be covering all of those other cases.

And it also makes it easy to add another one; ooh, yeah, what if somebody passes in a string [laughs] instead of an integer? And I can easily specify that context. I'd like to only have to specify that, well, A was the string hello. But I would not specify at the top of my file that there's a string called hello. That would be local, completely local to my...by passing a string test.

DAVE: Yeah. There's two bits to this, and we might be in violent disagreement. Or my answer might be we can still be friends because I believe in love the sinner, hate the sin. We're talking about, like, the distance, and I keep using this stupid law of gravity, right? What's the hardest place to keep a rocket? The answer is not on the moon or across the solar system. I mean, those are really hard places to put a rocket.

The hardest place to hold a rocket is about 500 feet off the ground. And so, for anybody listening...we should put this in the show notes. I gave a talk called Some Truths About Some Lies About Unit Testing. And, in that one, I talked about, you know, not using lets, not using these things, and the cognitive load on the distance.

MIKE: So then we're in agreement. [laughs]

DAVE: Possibly. Oh, oh, I talk about in this that we had had a codebase kind of implode where we were getting these Jira tickets, a feature request: Please make it so that the user can put favorite color on their profile, right? This is just one piece of data; add it to a user. It shouldn't be a problem. But it would break everything. And I would go to fix it, and I would find out that users were actually defined in a shared context way over here.

So, I'd go over there, and I'm like, okay, we'll add favorite color equals blue, and half the test suite would explode because they're asserting the user must have this exact interface. Or, we actually have some users coming in from this healthcare system that are expressly forbidden by law from having a color preference. So, they cannot even have favorite color on their profile. It's against the law. It's a violation of TCPA, I don't know, whatever, right? You know, some communication standard.

It's like, wait, what? You can't ask somebody what their favorite color is? No, no, no, no, no. But according to this standard, color means you're actually asking for ethnicity because it's skin color, and that's illegal. You can't do that. Oh my God, why are we talking about skin color? I just want [inaudible 40:56]; my favorite color is blue, right?

And what happened was this codebase collapsed on us. And we were getting these silly things that should have been zero story points that were taking us a week. We had a one-line code change, half a line, half a line of code, one side of an equal statement. And, you know, if X equals Y, now that's a branch. So, that half a line of code actually had a big effect later down in the code. But yeah, it was a thing within that shared context, and half of the suite needed X to be equal to Y, and half of the other suite required that X never be equal to Y.

And we came up with a way of solving it, which is we came up with this let that this [inaudible 41:38] would check locally when it was creating itself. And we would then invoke this context to go get that thing which would call back into us. Do you understand, like, the cognitive distance on this is, like, 4.21 bazillions, right? It was way too much.

What I discovered from this is that we would do context da-da-da-da, and then we'd have, like, a before block, or we'd have some lets. And the hardest test, almost as hard as understanding a shared context that calls back into some excluded examples, which are in another file, by the way, which calls into a let locally, almost as hard to track down was a let at the top of the file that says, you know, we're going to work with, you know, the addend and the augend, fancy words for two numbers you're going to add together. We're going to define these to be 5 and 7. Halfway down the file, we have a new context called, you know, incorrect math. And there we say, let B equal 7.

So, now A and B are both 7, right? So, the correct answer should be 14. So, what you do is you're like, uh, what's A? What's B? Oh, they're at the top of the file, 5 and 7. But why does this say expect the addition to be 14? Finding that before block, it's in the middle of a file, and that file is 2,000 lines long because as much as you want to be a good programmer, sometimes entropy gets away from us. It's not great. We don't like it. We shouldn't do it.

But yeah, oh man, if we're talking about, like, we define this beautiful document, and then halfway through the file, we build this overlay that, hey, I'm just going to paper over a different value for the password or paper over a different value for this variable and then the rest of that context asserts something behavior based on that, super, super painful.

MIKE: Oh, and I would agree with you strongly because they shouldn't have overwritten that unless it was context-specific.

DAVE: Yes. Yes

MIKE: And so, we're in complete agreement because the minimal rule applies.

DAVE: Yes. I love that minimum rule that you should basically say, whatever this variable is, gravity should hold it right there, not just to the same test block but to the same line of code. This was the example I used in my talk where I talked about, you know, expect 5 plus 7 to be, well, you don't need any other lines of code anywhere. You don't even need to look two lines up at the top of the it block and see the A and B being defined.

And the beauty is, is the very next test says, expect hello and world added together to be hello, world. You're like, oh, it can add strings. Like, you know that instantly from one line of code. Again, that's getting back to, like, exemplary data, which is an artistic thing. Exemplary code really falls apart when the example has something subtle about it that makes it break. You don't want to do that. Then you actually want to say no, no, no, this is invalid because the parity bit is off. Give it that name. Don't give me exemplary data. I'm like, why is that off? Oh, it's 43 characters of hexadecimal noise instead of 44. You can't see that from an exemplary data.

I will hammer one last time; imagine you are reading the Stack Overflow answer. Or, if you're older and you remember, like, MSDN, which was this thing where you could say, "Hey, how do I log into the database?" They would give you, like, seven lines of code in whatever, you know, Visual Basic, or C++, or whatever language we were working in, would give you seven lines of code. And those seven lines would compile because everything was defined, everything that you needed.

And if there was something that you needed that was special to that block of code, they would say, somewhere else, you need to put this. That's something that you could put in a before block, or a let, somewhere else. Everything else was gone, but everything that needed to be in the answer to that document to give you everything you needed to know was right there. And it's beautiful.

I will tease this. If we do another episode, there's a difference between duplication and repetition. In a unit test, you should not DRY up your code. DRY is Don't Repeat Yourself, right?

MIKE: That's another episode, but I agree with you.

DAVE: That's a whole other episode. You want to do WET, which is Write Everything Twice or thrice or, you know, whatever. Duplication is not the same thing as repetition. An example of that was those users that one of them had to have color and one of them couldn't. Those were completely different classes of objects. Why were we reusing the user class for that answer? Because it was duplication. We dried it up. Oh, it hamstrung us for a week to add that zero-point feature.

MIKE: [laughs]

DAVE: I'm done. I love you guys. Let's do another episode.

MIKE: Thank you to all our listeners. Hopefully, you've gotten some greater insight on how to use RSpec. Talk to you next time on the Acima Development Podcast.

The conversation revolves around the importance of mentorship in various aspects of life and career. Dominick compares mentors to influential figures like sports coaches and speaks about his father's guidance in his career choices. Eddy expands on this, likening mentors to a "cheat sheet to life," helping to avoid mistakes, and assisting with connections and encouragement. The discussion emphasizes that mentorship is not only about guiding others but also about having the love and enthusiasm for the subject, sparking curiosity, and engaging others.

Mike's perspective adds depth to the conversation by sharing his personal experiences both as a mentee and a mentor. He highlights the value of mentorship in launching careers, the commonalities in mentoring, and the importance of non-traditional roles. Mike also stresses that mentoring is not just about having more experience but about providing a sounding board and additional perspectives. Ramses agrees that mentors can save time, especially in technical issues like debugging.

Kyle brings an insightful viewpoint on the reciprocal benefits of mentoring. He explains how mentoring others has helped fill gaps in his own knowledge and emphasizes that true understanding of a subject comes from being able to explain it to someone else. Everyone concludes with a universal agreement on the pivotal role mentors play in personal and professional development, growth, and success, highlighting the human elements of curiosity, passion, communication, and the willingness to share and learn.

Transcript:

EDDY: Hello, everyone, and welcome to our podcast session for Acima. My name is Eddy. I've been in the podcast sessions prior. And today, we have Sergio Peralta, Ramses Bateman, and Kyle Archer. Today's topic is actually really interesting. And I'm actually really fascinated to get other people's perspectives. Who are/were your mentors, and how do they help you?

And I can sort of start since I do have kind of an idea of, like, how integral it is to have mentors and applying that logic to anything really, not just engineering as a whole. I think, in general, just having a mentor enforcing, you know, for your mentality and, like, advocating for you. And we can deviate from engineering if we need to or even in development and kind of get the perspective from QA, right? Product managers if we can. We got Kyle, who's from DevOps. I think that'd be kind of cool to get his perspective as well.

I'm probably not the prime example that we can use. But essentially, just speaking for me, before I even decided or even flirted with the idea of becoming a developer, and I was hitting my late 20s, and I didn't know what I wanted to do, right? It was sort of, like, a dead-end job, no room for advancements. And was kind of, like, [inaudible 01:28] my depression personally because, like, I had no room for growth. I started questioning my life decisions.

And then, my older brother would tell me, like, "Hey, man, like, you should consider picking up programming, you know, I think that might be a really good idea for you." And, at that point, he had been developing for, like, 10-plus years. And so, like, he kind of guided me at the beginning, gave me ideas of, like, what to look at. And so, I ended up looking at YouTube videos on, like, tutorials on, like, how to create your own projects and doing online courses.

I didn't really get very far, personally. I kind of hit, like, a dead end. And I was, like, dang, like, it's really hard to stay motivated when you're shifting career paths like that without actually getting paid because it's kind of, like, a second job without pay until you're able to get the skills enough to convince someone to hire you. And so, it went on like that for almost two years of, like, constantly grinding.

And, at one point, I even went to college, right? I decided...I'm, like, I can just do this by myself. I reached out to my older brother, and I'm like, "Hey, man, like, can you give me some resources on what I can do to kind of kickstart, you know, my knowledge?" He sent me, like, Codewars before. And so, I did a few courses on that. And then, I even flirted with the idea of doing a bootcamp. But my biggest thing was just having the discipline to, like, not stay in the same job that I was at.

So, me personally, having a mentor when you're going through that change of the career, all the career choices—it doesn't matter, like, if you're a kid or you're an adult—there are going to be some times where you're confronted with challenges and, like, you have to innovate and write your own solutions, or come up with you own solutions. And that can be kind of daunting at times and a bit overwhelming. And so, having a mentor, you know, provides a lot of that ease of pain. So, like, they can cheer you on any time you're down. Like, they can provide some sort of, like, policy or, like, a guideline to enforce the decisions.

And, you know, they can advocate for you if they are in the same industry as you. You know, they can give you, like, a recommendation eventually, you know, when you feel like you're ready, or even, like, a study buddy. Having a mentor that can sit by you and kind of get you unstuck is super valuable. And that's kind of my origins and my idea behind why having a mentor is really important. And I think that was integral for me to landing my first job in the engineering department.

KYLE: Before we started recording, we were kind of talking a little bit about the different engineering departments. And that's something that's, to me, a little bit interesting in software. I came through, and I did first seven years, I believe, in engineering. I did that in the QA focus. And I had the opportunity in the QA focus to have what I feel like was different sets of mentors. I did have my QA mentors, one, you know, being a co-worker and several bosses that were always out to have my back.

But I had also, like, dev mentors and IT mentors that were willing to show me the ropes in IT, and some that were willing to show me the ropes in the development atmosphere that were, how could we get QA involved in here? How could we get QA coding? You know, one job I was a...they called it a dev QA. I was on the QA team, but I worked directly with the developers. I was on a team of four or more developers. And it was just me as the QA, right? And, of course, not both...they want automated tests. They want API tests. They want that type of thing.

And, you know, some of the time, they have to kind of teach you how to do that coding. So, I had those kind of, you know, mentors. Getting more into the QA automation side of it, I ended up getting a boss, and I'll name-drop him—Nelson. He was a boss that I had while I worked at a company called InsideSales. He ended up seeing something in me that others hadn't and gave me a chance to code. And he brought me on to this monitoring team.

And while on that monitoring team, I feel like between him being a mentor and the political atmosphere, and giving me confidence to be more of a lead on my team and stuff like that; he helped me there. But it also gave me the opportunity to work more with DevOps. And in so, I ended up getting what I would call, you know, DevOps mentors. And there are a few great people that I would still consider mentors, and I appreciate their assistance, you know, getting me going in DevOps.

And so much that where I'm working now at Acima, one of those mentors is here, and I'm working directly with him. It's just interesting. You can look directly for your specific field to find what mentors are available to you. But don't ignore the mentors that are in, you know, other specializations: QA, dev, systems, IT, all that.

EDDY: Kyle, you mentioned something, and I'm just kind of curious. Prior to the monitoring team, that was the first team that you joined. Was that the first team that kind of got you your start in the engineering department?

KYLE: QA is engineering in my mind. It was a job prior that I was more of a manual QA tester. But going up to that, I was more of an automated tester, you know, the Selenium-type tests. But going to the monitoring team that I spoke of directly, there was a bit of Selenium, but we used a framework called Robot Framework that's based in Python. But then, we ended up writing direct Python scripts as well to do some of the testing, which would test, like, phone calls and stuff like that.

EDDY: That's awesome. What's your opinion behind having a mentor? Do you think that's important? Or, rather, can you be successful without having a mentor? And adding on top of that, do you think you would have been successful had you not had a mentor?

KYLE: I'm kind of thinking I could have been successful. But I don't think that I personally would have been near as successful. I don't think that I would have broken into the different specializations very well without somebody kind of showing me the ropes, showing me these are the things you can do and what to do. Because I feel like a lot of the time, without a mentor, you don't really have a direction. You're not...you kind of have an idea of what needs to be done. And a mentor with experience is going to have an idea of how to accomplish it, even if it's old technologies with a new face. What I'm thinking here is Vagrant.

So, at my previous job, I used a tool called Vagrant. So, having somebody to show you how to use Vagrant was really good. And then, you know, when everybody started adopting more of the Docker practices, that was a lot easier to jump on board with. And having the discipline on my own to know when and how I should switch from a tool like Vagrant over to something like Docker, I'm not sure if I would have been aware of that.

EDDY: I agree. I kind of share, like, a similar sentiment. It becomes difficult to understand, you know, new technologies when you're first getting in and, like, to differentiate between, like, what's working, what's new, what's not working, the pain points of either. And, like, having a mentor that's already been through those pains, you know, kind of gives you a shortcut to that success. Actually, that's sort of, like, a cheat code, right? Like, if someone has already gone through that struggle personally and they're willing to share that advice to you so that you don't go through the same struggles, [laughs] I think that's part of a reason why I really enjoy mentors.

SERGIO: I feel like in my time in the university, yeah, I have good ones. I can say a couple of my teachers who were good mentors. But they have tons of teachers. So, I feel like it's a lack. I don't know if it is only my country, but it is something like people really interested in you learn. So, that's a reality about mentors, like, people that they care to you. They care what you're doing. They care what's the route you're taking.

So, since in the past, I had a few contacts or few mentors help. I just try to convert in a mentor when I was a teacher. So, I tried to do this to my students. I tried to do this with the people I was working, even if I have few context, I was trying to do that, and that's because a lack of mentorship in the past. And you made me figure out this. [laughs] And now I understand why because I lack of this.

And it's not funny, but that's made me try many things, just try many languages. I tried many, many stuff until I got a clear path what I wanted to do. So, I guess if I had a mentor in the past that helped me, I guess, right now, I would be in a better position. So that's my perspective. It's sad, but it's not bad at all.

I don't know if this is something from my country, or it's something in the culture in my country that is not allowed people to show you or guide you in some ways, you know. So, that's my input. It's, like, sad, but I just try to do mentorship for others. And even I work with my students on projects and open-source projects as well. So yeah, that's awesome.

EDDY: Sergio, that's kind of interesting. You kind of come from a mentality of being a mentor versus being mentored, right? So, I'm kind of curious to pick your brain on, like, what are the commonalities that you typically find when you bring on a student? What's kind of the struggles that you see when you're mentoring someone?

SERGIO: Most of the people that need mentorship they don't know where is the future. They don't know how these tools, how this stuff will help in the future. The main struggle that I saw, at least in software development, at least in my country, is, like, they don't know so much about software. They don't know so much about tools, and they didn't know how they can do.

And even if they are interested in money, if they're interested in build stuff, probably they lose the path of learning one thing. And probably a good mentor can say, "Hey, you can learn this bunch of things. You can accomplish this path. You know, you can accomplish being a software developer, and you can accomplish being a QA." But they have so few context, and they didn't know what is the right path. That's the thing I notice, at least here. You know, I'm not talking about globally, you know, but that's my opinion.

EDDY: Yeah, that's awesome. That's really cool. I kind of want to deviate a little bit to Ramses because you've kind of played the role on both, I think, from actively mentoring the people in the company people reaching out to you for help. But at the same time, you've been through that pathway as well, where you've reached out, and you've gotten help. So, I'm kind of curious on your perspective on, like, the value behind mentorship.

SERGIO: You mentioned something really important. Right now, I feel like actually I am switching back between roles. Yeah, since I lack some knowledge in the stack, Eddy and many people here is explaining me some stuff. And at the same time, I have experience in areas that I am sharing this knowledge. It's part of the culture of this company, and that's awesome. So, I like it so much.

EDDY: I agree. I can attest to that.

RAMSES: Yeah, I've been on kind of both sides of it, probably more of the receiving mentorship than providing mentorship. But I do tend to find that I like providing mentorship. Mentorship is interesting. I don't know if it's necessarily needed, but I do find that it's very helpful. By yourself, you could figure out how to do things, but you might not necessarily know all of the why, why something is done a certain way. So, having that mentorship or someone to mentor you and kind of walk you through why certain things, you know, happen or how to do certain things, I think, is pretty valuable.

EDDY: Did you have mentors when you first started, and was that integral to your success?

RAMSES: Yes and no. I'd say I had a few mentors. A couple of the senior developers and product managers were pretty integral in providing me the opportunity to expand into different roles and have also been just thrown into essentially a firehose of different situations. But I think with their help; they provided me the tools where I don't necessarily need, you know, that assistance or that, like, continual mentorship. They provided me a good foundation of resources where I can work out the solutions generally by myself. But if I obviously need some sort of assistance, I can still reach out to them or reach out to, you know, my other peers.

EDDY: Yeah. And I think, primarily, most of my mentorship, since I started, has come from Acima for the most part, and I think a lot of us from this call since we've been employed can kind of attest to that, that having mentorship when shifting projects or something that's asked of you that you have no knowledge in is important in order to find success.

Dominick is actually one of the interns for this year at Acima. And I'm actually kind of interested because you kind of have a different perspective than all of us. I don't know of any of us, and please correct me if I'm wrong on the call that have been involved in an internship. So, I'm kind of curious to kind of hear your perspective since you're kind of going to school. And kind of give us your perspective on how important it is for mentorship.

DOMINICK: I personally find that having a mentor is a pivotal part of being able to be successful, at least for me. Like, I know that Ramses had mentioned, you know, you're able to figure out a lot of things by yourself, you know, you might be able to get a task complete. But as to why those things work or why you're completing that task, I think those questions are better answered by somebody who has a little more insight and knowledge compared to what I have, at least. That's why, so far, this, you know, the internship is great.

I really enjoy being here just because it's a little bit different than actually going to, like, school, different classes, and stuff. Because in classes, yeah, you're going to learn about fundamentals and concepts of things. But here, you're actually able to apply those things to a real business environment, which is super awesome. Because just the fact that I'm able to come in every single day and learn something that will be useful for my career in the future is just, like, it's the best. You know, it's a great opportunity, for sure.

But as far as, like, mentors go, yeah, I think it's very important. I've played sports, you know, forever. And some of my most influential figures in my life are coaches that I've had. You know, I had the same coaches for over 12 years, and I still interact and talk to them to this day; you know, they have earned my respect. And, hopefully, I've earned their respect because I guess it is a two-way street. But just having somebody that's more knowledgeable is always a key.

EDDY: I'm actually glad you mentioned sports because this goes to show that, like, mentorship or having a mentor, in general, is key to finding the motivation and getting you unstuck. You mentioned sports, right? And I think that having someone guide you and motivate you to kind of move forward that's the key, right?

DOMINICK: Oh yeah, absolutely. Personally, I'm a fan of...I know tough love is kind of going out of style nowadays, and it's got to be all nice and rainbows and butterflies, but, you know, some constructive criticism, I find, it is a good thing in my opinion.

EDDY: And when you decided to go to school for development, did you have a mentor to sort of guide you on, like, selecting development? And if you did, were they integral on, like, helping you advance as far as you have?

DOMINICK: Yeah. I always had an idea. Like, I really always enjoyed using computers growing up. I was always playing the OG Microsoft Pinball on, you know, your 2005 box computers. That was, like, the greatest thing ever to me. So, I think that formulated my opinions on it. But I always liked using computers.

My father is actually...he recruits software engineers, like, he's a software engineer recruiter. So, having him to kind of motivate me and be, like, hey, like, look at all these people that I'm hiring and the success that they're achieving, and the things that they're able to do because of the career path they took. I was, like, that sounds pretty cool. I think I'm going to have to check it out. So, those two things kind of combined together definitely gave me inspiration for where I am currently.

EDDY: That's awesome. And, I mean, you had a dad as a direct influence who kind of set that path for you, right?

DOMINICK: Absolutely. Yeah.

EDDY: [laughs] So, to some degree, your dad sort of was a mentor.

DOMINICK: Oh, 100%. Yeah. I mean, I always say he is my role model for everything. He's the hardest-working individual I know. So, having him as a mentor is great because it's, like, I want to strive to be just like this man, and I try to do so every day. Yeah.

EDDY: Awesome. So, we got Mike Challis, that joined. Mike, you've been mentored, and you are a mentor. Am I right in that assumption?

MIKE: You're correct in both respects.

EDDY: I'm kind of curious to sort of pick your brain from the origins of being mentored and, like, kind of how far along you've come and be on the other side of that coin to mentor other people.

MIKE: I'll start by just calling one person out. A lot of years ago, I worked with a guy...maybe I'll just call him out. His name was Craig Moon. And he was not just a boss, but he was also a mentor. I came into a job out of school. And I had done some software adjacent work before, and I'd even been doing some part-time work before this job. So, I'm not going to say it was my first software job, but it was the one where I was really working full-time. And it was my first consistent, full-time software job.

And we were in a small office. [laughs] And it was very easy to just kind of turn around and say, "Hey, I've got a question." [laughs] And having him there and as well as my peers who were there, made a tremendous difference in helping me learn the ins and outs of web development. I had been focused, before that, really on more technical. I'd done a lot of kind of graphics development, you know, focused a lot on linear algebra at a really low level, close to the hardware.

Jumping up to web development was a real shift. [laughs] Having somebody who really understood what was going on in web development as well as the language I was working in...I was working with a language that I wasn't that familiar with. And having that kind of anchor to give me a center as I was trying to figure everything out was hugely valuable. I still think back all these years later to this example and want to emulate that.

He focused a lot on databases and starting with your data and thinking about what your data should look like. I still carry that with me, you know, decades later. That mentorship made a huge difference. Later on at that company, [laughs] he ended up leaving, and I ended up being the only developer for a while. We went through some downsizing. There were a lot of times I wished I had his guidance again. [laughs]

And I learned a lot when I was running things alone, and things I probably would not have learned had I been able to lean on a mentor. But on the flip side, I would never have gotten to the point where I could even consider doing that had I not had a mentor to lean on previously. So that kind of answers the first question: a mentor is incredibly valuable for launching your career and has continued to be valuable other times. And I'm going to take that a step further.

And sometimes that mentorship comes and maybe usually even doesn't come from somebody who's far more experienced than you are but rather from a peer who has some insight that you don't have. Being able to have that sounding board is a great source of confidence in being able to move forward without feeling like you're making a misstep because you're blind. That second pair of eyes is just hugely valuable.

And sometimes, we think that we have to know everything to be a mentor, a lot of times, that's not the case. We just have to be able to provide that sounding board, that second pair of eyes, that additional perspective that helps give somebody confidence in what they're doing.

Your second question, I've spent a lot of time mentoring as well, being in the role of a mentor. And I've seen a lot of people go on and be really successful. I think that one of the best things that you can do in your career is take the time to mentor people. It's kind of paying back. And so, I could say, you know, it's just good citizenship. But further than that, for me, it's been the most rewarding part of my career. Being able to help other people become better at what they're doing is, I think, more gratifying than anything I do.

Yeah, there's that huge thrill that you get from solving a nasty bug or from reaching a point where a feature is working that's a little hard to express. Absolutely, that's a wonderful part of software development. But I think that even more rewarding, is helping somebody and letting them get to that point, helping them reach that point where they have that epiphany, whatever hormone it is, maybe dopamine [laughs] that you get when you hit that moment where it works. Being able to see that in somebody else, I feel like, is even more rewarding than when you've accomplished it yourself. So, even if you're selfish, [chuckles] it's worth doing.

But more than that, because most of us are not purely selfish in that respect, you know, we work together as social beings. Investing the time in your peers gives you the community you'd want to be a part of. That is worth doing. I would highly encourage anybody in a position to give some mentorship, when you can, to take a little time and do so, even if it takes you away from getting that project done as quickly as you were going to get it done.

You are expanding your reach. You are helping other people become more effective. As a team, you become more effective when you do so. And it's personally gratifying. It's effective for the company that you're working for. And it's just the nice thing to do. [laughs]

EDDY: So, how long would you say that you've been in the role for mentoring?

MIKE: I'd have to think about the exact year. But there's somebody who's working with us here at Acima that I was a mentor to at his first job about 20 years ago. So, [laughs] I've been doing it for a while.

EDDY: Through those times, right? So, those 20-plus years that you've been a mentor, for someone who's actually listening to this podcast and is seeking or maybe looking for a mentor, what are some commonalities throughout the years that you've found between mentoring other individuals? Maybe you kind of consolidate all of them. I'm sure there's some overlap.

MIKE: There is. One thing that I would say is that people, in general, want to learn, but a lot of times, they are not sure what path they can take. People know that they would like to expand their skills, that they'd like to expand their career. They'd like to do something cool. But they don't know where to step. They don't know what to do next. And so, we kind of follow inertia. [laughs] We stay where we are because we don't see an avenue to go somewhere else.

Something that I've seen repeatedly is that taking some initiative and reaching out to somebody, somebody that may not even be what you traditionally think of as being a peer. Reach out to somebody who's in customer support, for example, or somebody who's sitting at the, you know, the reception desk, or somebody who's doing QA, reaching out to people like that. Just always having an eye open for somebody who's expressed some interest and providing them some opportunities to learn has paid great dividends.

And I'm thinking about specific examples for each of those roles. I'm thinking about somebody who worked at the reception desk who's now a manager for the software department, you know, the engineering department at a company. They went from, you know, working as receptionist to, you know, she's now working, you know, as, you know, leading the entire company's development team. I mentioned somebody in customer service. I've seen somebody from that role go on to be a software architect for a company. Another person from doing customer support, I'm thinking of, that has gone on to have a very successful software career, people from QA who've gone on to be very successful.

So, you know, all of those may be non-traditional roles. And I've mentioned this before on the podcast. I've seen people become very successful. And I try to say this regularly, that you don't have to come from a traditional background necessarily to be successful. You just have to [laughs] be provided the opportunities and then latch on to them and don't let imposter syndrome get to you. Just keep working at it.

Well, a lot of that only happens if you have a mentor who is willing to help you out because, otherwise, you just don't even know where to go. You may have all of the initiative in the world, all of the interest, all the motivation, but it's really hard to use that if you don't even know what to do. Sports analogy has been mentioned. And I think they're very fitting. You can practice your sport all day long, and if you're practicing with bad form, you're not going to get much better. If you have a coach who can teach you how to improve your form, you'll be able to progress in your sport much more quickly because you'll be practicing the right way.

Similarly, a mentor in software development will kind of tell you which way to go. They will be able to point you in the directions you can build your skills in ways that you're likely not going to see on your own. Now, you can listen to a podcast like this or, you know, do some reading. There's things you can do to grow your skills independently. And yes, you absolutely will get better.

But that mentor can really give you the direction that can help you develop your best form and more quickly actualize yourself, step into the places that you should be, rather than making a lot of missteps, rather than down a lot of dead ends because you read something you thought that was valuable, but really, it would have been more effective for you to, you know, put your effort somewhere else. And a mentor can really be that coach, and we have coaches for a reason. [laughs] We don't usually have teams that are self-coached because the coach can really provide a tremendous amount of assistance. A mentor can do the same.

EDDY: So, I sort of, like, see a mentor as, like, a cheat sheet to life, and let me kind of elaborate on that a little bit. A mentor typically means that they have more experience than you, meaning they've gone through the pains, and agony, and bloodshed, and tears, you know, the things that made it complicated for them. And now that they have hindsight, having them being a mentor to you can help you avoid going through that same thing.

So, if you have someone's attention and they're willing to provide mentorship for you, I think you should take it, right? I've spoken to a couple of people who say, "Oh no, I don't need help. I can do it by myself." And I'm like, sure, of course you can. Absolutely. But, like, if someone extends their arm and they're wanting to help you, I think it'd be kind of silly to not consider that as an option.

RAMSES: Yeah, it shaves off tons of time. Debugging an issue yourself for two days, or reach out and get the answer in, like, 20 minutes.

MIKE: And that's not an exaggeration either, right? [laughs] It really is that kind of tenfold or a hundredfold difference in how quickly we can progress.

RAMSES: Oh yeah, definitely.

EDDY: I do kind of want to ask this one thing to anyone who wants to provide some feedback on that. But what are some good characteristics from someone you're looking for when you choose them as a mentor? What makes that person a good mentor? Some of the things, like, that I would see, like, the benefit of having a mentor in the beginnings, right? Or even later on in your career. They've helped me, you know, make connections, you know, with, like, networks between other people who are in the industry, right? So, they can put in a good word for you once they see the value or, like, the progress that otherwise other people wouldn't have seen, right?

Like, mentors have in the past given me, like, encouragement to continue forward. They also, like, have provided, like, accountability for me on, like, "Hey, where are you at? How's your progress going?" et cetera. I always see them on my ringside.

MIKE: I would say, think about your favorite teacher that you ever had. And what are the characteristics that made that teacher your favorite? For me, a lot of that is childlike curiosity and playfulness about the subject. When I say passionate about what their subject is, is they have a passion about it. They have a passion about it because it's fun, right? It's something that they want to be doing. They just love learning. That love is contagious.

I think of some of the best teachers I've had. And they were people who really cared about the subject because they say it sparks joy [laughs] [inaudible 31:56] Marie Kondo [laughs] who said that. Find the thing that sparks joy. Well, the teacher found something that they loved learning about, and then they kept doing it and shared it with the people around them and chose to do so.

If you can find somebody who has that love and enthusiasm for their craft, it would be maybe the first thing. And you think, well, what about the rest about, you know, being able to reach out and help you? And all of that is true, but it kind of comes downstream, I think. Somebody who is obviously showing that they love what they're doing is trying to involve you, right? The fact that they are showing it means that they are engaging you socially. If you can see it, it means that they're actually communicating it because somebody could love something in silence, and you'd never know. There are outward signs. They want you to get involved.

Somebody who invites you over, like, "Hey, come look at this," is somebody that you should, I think, immediately start considering as a mentor because there is somebody who has volunteered to show you something. They see something in the world that they like, and they want you to experience it with them. Somebody who wants you to have that shared positive experience is somebody that you can probably trust to want to do that again and is worth showing some vulnerability to and be willing to let them help you out.

EDDY: I agree with everything you said, Mike.

KYLE: One thing that I've kind of thought about as we've gone through this, we've talked a lot about being mentored. And I was thinking about how I wouldn't say I've had very many opportunities to actually mentor individuals but the ones that I have, I've found it to be actually helpful to myself, too. Whenever I've mentored somebody, an individual generally will end up asking questions or seeking insight that I may not have information about or, you know, that I've never really thought about. For me, it's been good because it filled in some of the gaps in my knowledge, I feel like. I would say there, too, if you get a chance to mentor, it's something that will benefit you, as well as whoever you're mentoring.

EDDY: Someone once told me something a while back, and it sort of just stuck with me. It's like, you can't really claim that you understand something unless you can explain it easier to someone else, like, only then can you, like, truly say that you truly understand something.

KYLE: And I feel like that's kind of the path. Generally, when I'm learning something, me personally, maybe others take a different approach, I walk down the happy path. I walk down the needed information. And then I say, okay, well, I've got it; I'm good, you know. When you're teaching somebody, trying to explain it to them, they may not be walking down that same path. They're looking for a different answer. They saw something over in the corner that you never even thought to look at.

EDDY: Agreed. Yeah, like, it helps you instill that topic, like, in your brain further because, like, when you're able to explain something, I feel like it really helps. All right. Well, this was a great session.

Panelists discuss the contrasting mindsets of focusing on the destination versus the journey in personal and professional growth. Dave initiates the topic, emphasizing the importance of a growth mindset that values continuous learning over mere achievement. This theme is further explored by Eddy, who talks about the significance of embracing challenges and discomfort to foster growth. Mike and others delve into educational theories like Lev Vygotsky's "zone of proximal development" to illustrate how discomfort can lead to substantial learning.

The discussion moves to real-world experiences, sharing insights into the rapidly changing world of technology. Kyle's insights about the importance of understanding concepts over tools lead to a thoughtful debate about coding bootcamps, their role in jumpstarting careers, and the importance of ongoing learning. Sergio's experience with on-the-job learning and risk-taking further emphasizes the importance of hands-on experience and the ability to adapt. Everyone shares personal examples of how learning outside of work has shaped their professional lives, highlighting the need for continuous growth.

Transcript:

MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I'll be hosting today. Today with us, we have Dave, Kyle, Eddy, Sergio, and Tyson. I think we'll have a good mix of opinions here. I'm excited.

We are going to be talking about how we manage to stay learning and growing our skills when there's always work to do. There's always something else to do. This is a challenge for all of us.

I want to start, as I like to do, with a story or two. I'm going to start with a kind of a fail story. I was a few years into my career. I was at a company that got into a tight spot financially and laid off the development staff, all but one. And then he quit. And they ended up hiring me back on. [laughs] I came in not being the senior developer on the team, trying to pick up where the lead developer had left off. And, you know, he gave me some guidance and laid out some things he'd been working on, and, like, away you go. Good luck.

So, for about a year, I was running things by myself. So, you know, I had my choice as to what to work on every day. And we were largely in maintenance. We weren't really adding new features. One thing I discovered is there were a lot of manual jobs that we had lined up. And this applies to more than learning, by the way. We had a lot of things that needed to be done manually. This company was a content management system. And we had to set up email addresses for a lot of our customers, as well as some other things. And it was a somewhat manual process. I knew I had to do that every day.

And I noticed after a while that all of the manual tasks that needed to get done consumed more hours than I had in a day, and as well as all the other miscellaneous support requests. And I struggled for that year as to how to prioritize my time. There were things that I let slip because I was working on other things. And I just kind of really struggled to get all of the things done because there was absolutely more to do than I could do as a single person on the team, where we previously had a team of about six.

I thought about that in retrospect quite a bit, about what I would do differently today. I'm going to kind of leave that story there for a second and come back to it. Another story I've got is from the last year, and it's outside of work entirely.

My oldest son went to college. I used to ride a bicycle with him every morning, almost every morning. We'd go out and ride bikes, all-weather. We live in Illinois, so it's winter more than half the year. [laughs] So, we've got bikes that are built appropriately, big, fat tires. We'd go riding in the snow, and we had a lot of fun. And kind of the day he left, my daily rides pretty much went away because I had other priorities. I would be spending a lot more time with my other kids. Well, it's something that I still enjoy, that I like to do a lot.

In fact, this morning, my son is back from college for the summer. This morning, he and I went on a bike ride, and I had a great time. It's something that I really enjoy. But when I didn't have the person who was really engaged in doing it (My younger kids think it's too cold in the winter.), when I didn't have somebody who wanted to do it, my priority suddenly shifted, and it just didn't happen very much anymore. So, I'm not that interested in going out alone.

These two stories, I think, say a lot about me, at least, [laughs] I think also about human nature. When we're confronted with more things than we can do, we tend to latch on to something that's maybe easy to do or that we're familiar with. It's hard to take a step back and look at all of the things that need to get done and prioritized and say, "Well, here's something that's not necessarily urgent, but it's important. And if I don't do it regularly, then the whole system is going to fall apart." And this applies to paying down tech debt. It applies to, you know, a lot of things in life, eating good food, [laughs] nutritious food.

But, in particular, today, we're going to be talking about learning. And I think that it fits very much into this first story of, well, you've got all these things. How do you possibly fit the learning in? And the other story, I think, reveals a lot about how you keep yourself motivated to do something. We tend to prioritize, I think, as humans, things very socially. And if we've got a partner in something, it makes a world of difference as to whether we're interested in doing it.

And people sometimes talk about that as accountability, but I think that's inadequate. It's an inadequate representation. Accountability suggests that somebody's making sure you're doing something that you ought to do, that you maybe don't want to do. But I think it's a little bit different than that. I think that there's some things that we actually really enjoy doing and want to do but only find ourselves motivated to do if we are in some sort of social situation, if there's somebody who's doing it with us because, otherwise, we'll tend to prioritize something else that is also good because there are many good things to be working on.

If there's something that you really care about, one of the best ways to make it happen is to have a partner. There's, I think, a lot to talk about how you manage to get learning done when you've got all of the other things to do. I think that I'd like to start with those couple of ideas, which are that prioritization is hard, and somehow you need to make that work.

And secondly, anything you want to get done tends to happen much more when you do it in some sort of social situation. What are your all's thoughts about, you know, the ideas I've just shared but even, in general, about the topic today?

DAVE: Mike, you mentioned accountability. And there is kind of a sentiment that we have of if I'm not the one making myself do it, it's somehow cheapened. It's somehow it's not enough, right? We lack discipline, and we have a problem. And I got really struck by the book Freakonomics by Stephen Dubner and the other Steven. He points out that he caught a lot of people cheating. Now, he's an economist, and he caught people cheating. Because what he'd do is he'd open a spreadsheet, and he would just say, "This is not right. Your averages aren't average. I can tell which people are lying."

He then went around the world, finding different people that cheated in different ways. What he [inaudible 06:19] really shocking to him is that about 3% of the population are incorruptible. These are people who will do what they say. They will not cheat, and by cheating, is you go against the rules. No matter how easy it is to cheat, no matter how unlikely they are to get caught, and no matter how minimal the punishment if they get caught, there's no risk to this reward. And no matter how great the reward, these people, 3% of the population, won't do it. Just nope, that's wrong; I won't do it.

2% of the population are on the other end. They are incorrigible. These are the people that will cheat no matter how small the reward, no matter how likely they are to get caught, and no matter how severe the punishment might be. And that's kind of an interesting thing to find out. But the really staggering thing I see in there is that 95% of the population have a price.

There's an old Calvin and Hobbes comic where Calvin says, "Everybody has a price. Mine is 75 cents." I like that [inaudible 07:24] honesty. What does that have to do with accountability? We are social creatures. And when we have accountability, when we have a friend doing something that is, you know, going to be hard for us to do, but it's, you know, good for us, and we really ought to do it, I don't think it's a lack of discipline to grab a friend and say, "Hey, let's go work on this together." Or "Hey, what do you think about this?" And then get excited about it.

I don't think it's a lack of discipline. I think it's excellent planning and a great understanding of, like, our own conduct and, like, how humans operate, right? At the end of the month, if one person is like, "Well, if I don't force myself to do it, I lacked the discipline," and that person did not spend any time working on the new thing, and this other person that said, "I got to have a friend to get this done," and they worked on it every day for an hour for a month, right? The results talk, and I like the person that got the results in that.

MIKE: It sounds like you're running with the same idea I was that getting a partner in doing something is not cheating. It's recognizing human nature that we prioritize. Just innately, we tend to prioritize things we do together. I'm sure there's exceptions. Some people really don't want to be [laughs] involved with somebody else in something, but that's rare.

We're very social creatures, and recognizing that allows us to use that to do something that we really want to do together. And that's a valid and valuable way to get something done, and pretending that it isn't that way isn't going to help anyone. [laughs] It's just recognizing that's human nature.

DAVE: Yeah. I came across a quote a couple of years ago that said, "Half of being smart is knowing what you're dumb at." I came across this, like, back in the '90s. It was a long time ago. And sometime in the mid-noughties, I had this great epiphany where I realized that I knew what I was dumb at, but I was still trying to do everything that way, or I was letting people bait me into doing it the hard way and then I was failing.

And what I realized was what I want is the results. I don't want the honor of having done it right. I want it done successfully. That kind of led me to a personal epiphany that the other half of being smart is don't take on the world with your dumb.

MIKE: Taking this idea a little further, I think that most of us want to grow our careers. There's things that we want to learn, we know that we ought to, but then we face the first problem that I talked about. Well, where can we possibly fit it with all of these other things that take up more time than we have in a day? And that kind of leads to the two meeting, right? [laughs]

DAVE: Mm-hmm.

MIKE: These two stories connecting. If you want to get something done, schedule it with somebody. [laughs] And there are a lot of different ways that we can make that happen, you know, find a study partner and say, "Hey, let's get together for half an hour every day." Take a class where you pay for it, and you're going to go meet with a professor. Take an online class where there's some social aspect. You know, take an online class together with somebody that you know. Even better, start a book club.

Any of these involve the social aspect, where you've got something scheduled, and you've got somebody else that you're doing with. It changes the perception of things in your mind and is far more likely to make something happen than if you say, "Hey, you know, I'm tough. I can go [inaudible 10:37]."

DAVE: I like that. There's also people (I definitely fall in this boat.) who are kind of on the other end of the spectrum. Like, I never have to force myself to go learn something. The question of, like, how do you make yourself learn? In my case, it's a little bit like asking a cocaine addict, "What do you like to do," right? It's like, my problem is sometimes I will take on too much unknown just because I want to go learn it all, right?

And so, a lot of the strategies that I've had to learn are, how do I take this really cool, neat thing from a completely missing skill that I'm not skilled at at all, how do I turn that into something that I can sell? And I don't have a single clear, do this, and it will work. But I've got, like, 100 tiny, little hacks that I use that my goal right from the get-go is...actually, [inaudible 11:26] I was going to say my goal is to get to a point where an employer is happy to pay me. That's actually not true.

I just bite straight into the pleasure of finding things out. I just love going, oh, that's another piece of how the universe works. That's another piece of how the world really is. And if I just let myself play with things, that's the hack right there. Let it be play instead of like, ahh, I got to do this thing, right? Back off and say, what do you want to play with?

There's a time in the Atlas skills clinic when we stepped back and said, "Hey, let's look at, you know, game frameworks. Let's look at something silly. Let's look at something weird." And because that engages, like, this sense of play, you get this growth mindset. Instead of having the closed mindset of like, this is what I want to accomplish and have when I'm done, you look at it with the growth mindset of, what can I do to get into this process and get enmeshed and just experience the process, right?

The journey is everything. I don't even want to reach the destination. And ten years down the road, you realize that you've gone through thousands of destinations because you never stopped journeying. Does that make sense?

MIKE: I think so. You're talking about cultivating that child-like sense of wonder [laughs] that is hungry for it. If we didn't all have it, we'd never learn to walk. [laughs] You know, it's fun. I like to think that learning and fun are synonyms. What little kids like to do, well, they'll run around in a weird circle until they fall down. [laughs] It's kind of exploring the boundaries of what running [laughs] can do. It's fun to try out new things. And learning only ceases to be fun when it's kind of mandated, and we're often not actually learning but rather going through some sort of rote activity that has the trappings of learning, but it's not actually very engaging.

DAVE: Yeah. I came across a really fascinating, like, a micro-observation, and all these conclusions came from it that I'm still finding, and it blows me away. So, closed mindset is when you focus on the objective, right? The destination. And growth mindset is when you focus on the journey. And very specifically, if you're playing a game in a closed mindset, the objective is to win.

And, as humans, we want to do everything we can to optimize. We want the victory at, you know, the most victory at the cheapest cost. We want to put the least effort into this. We look at the thing we want to do, we want to get, and we go, ugh, how am I going to get this? What's the easiest way to get this? And when we look at growth mindset when you look at a game that has, like, an open-minded growth mindset, the objective is not to win; the objective is to keep playing, right? The objective on a growth mindset, you know, a journey versus the destination the objective is to keep journeying.

And the conclusions that you can draw from this is that when you focus on the outcome, you actually make it harder on yourself to take the journey because you just [inaudible 14:15], right? And I can give you a really good example of this, which is you walk into school on the first day, and you're excited to learn all of these great things. And then the teacher says, "And this is what's going to be on the final." And you realize I just got to get through this final and move on.

I've heard a student straight up tell a teacher, "Just tell me what I have to do to get an A." And the teacher got mad, right? Because the student did not want to learn the material. She just wanted to optimize and get out. She was basically telling the teacher, you are not important, and this subject matter does not interest me. How do I get out of your class with the minimum amount of hassle? Even though she said, she wanted an A, right? She wanted the highest grade possible, but, you know, she wanted to do 93% of the required effort to get an A, but she was not going to give 110.

MIKE: That ties into this idea of what we prioritize. I think it'd be helpful to expand the group talking here. Eddy, if I could ask you, what has helped you? I know that you're somebody who has really grown your skills. What is something that's helped you keep learning and growing despite, you know, all the constraints of things you've needed to get done?

EDDY: It's really just putting myself in uncomfortable positions, challenging my skill set in order for me to make sure that I'm learning something and just staying out of my comfort zone. After transitioning to full-time development, I realized, hey, you get assigned tasks about things you don't know anything about. Well, time to look up and try to figure out other blogs on Stack Overflow, et cetera, to figure out, oh, someone else ran into this problem. So, I'm constantly learning because the job...[laughs] that's the job requirement, essentially.

MIKE: That's really interesting. You point out something we haven't really talked about much yet today, which is that one way to make sure you're learning is to deliberately put yourself out there—maybe not quite jump in the deep end and drown—but put yourself somewhere uncomfortable and make that conscious choice. Choose to embrace that discomfort, and then you find yourself growing a lot. Is that a fair summary?

EDDY: Yeah, it's basically how I was able to learn as much as I did. Because the listeners may not be wary of this, but I'm just about completing my two years since I started coding, right? So, computer science or programming has existed for decades, right? So, starting a career path two years ago is basically drinking from a fire hydrant. But it is the only way to learn, at least for me, was just embracing it and just putting myself in situations where it wasn't comfortable.

MIKE: And I think there's a lot of power in that, and it connects some to what Dave saying. If you embrace the discomfort, it kind of changes what happens. Because if you're never uncomfortable, you're probably not going to stretch very much. Once you realize, you know, discomfort maybe isn't so bad, then it opens up a whole new world.

You know, I've seen you grow a lot. I've seen other people who have grown dramatically. It's because they've done something similar. They've been willing to put themselves in a situation where they might look dumb, where they might feel uncomfortable, and had to trust that it would work out. It means that you've got to be in a supportive environment.

If you're in a hostile environment where people are going to treat you badly, you're probably not going to learn very much there, and maybe you should go somewhere else. When you have a supportive environment where you have people willing to work with you on that, you know, jumping in is just so vital, [laughs], you know, to be able to grow quickly.

I believe that I've mentioned before on the podcast...it's such a powerful idea that I visit in my mind a lot. I know in education theory, there was a theorist named Lev Vygotsky. He was in the Soviet Union, and I don't know that his work was very much embraced there, but it's come to be widely used in education in the years since. And he suggested that people learn the most when they are in the space between what they can learn alone and what they can't learn, even with help.

So, between what you can learn alone, which is fairly limited, and what you can't learn at all, even with help because it's just too hard, in between there, there's a range. They call it the zone of proximal development. That range is where you learn a lot. You know, getting yourself in that situation means that you have to have people who are there to help you, and it means that you're going to be uncomfortable. That's where most of the learning happens.

Kyle, where have you found success in growing your skills, even though you've always got an endless pile of work to do?

KYLE: In my endless pile of work?

MIKE: Uh-huh. [laughs]

KYLE: That's about the simplest answer. I always say that DevOps work is very breadth work. You can be somewhat provisioned in a few things, but you have to know about everything. And I feel like I'm constantly working on stuff that I do not know that much about and I'm not an expert in. But, you know, give it time and trial and error. A few days later, and it's not half bad, and you've figured the system out.

MIKE: Interesting. So, you're in a position where you're frequently being confronted with new and challenging things.

KYLE: Yeah. I would say that half the job, if not more than half the job, is troubleshooting. It's either troubleshooting or spinning up new tech, or upgrading old tech that has new features. And with that constantly happening, you're having to pivot all the time to learn. You might get comfortable with one tooling in DevOps, and as soon as you get comfortable with it, there's a new tool out there. It's so rapidly changing. I mean, we've discussed this in previous podcasts, but DevOps today, compared to DevOps even a few years ago, three, four years ago, it's a completely different environment.

MIKE: And that's not so different from software development, generally. It's such a rapidly moving field. You're always a little bit behind, right? Always something to learn.

KYLE: I actually question sometimes with some of the training materials, right? I always wondered, in school, like, why are they teaching me concepts? You know, why are they teaching me theory? I want to know how to program in C#. I want to know how to program better in Java. Why aren't they teaching me these tools? Well, I mean, you get looking at it, and if our schooling taught us how to just use tools, we wouldn't be very far along. It's that there is just the concepts that we really needed to understand to move forward and be able to adapt to all the changes that we've been faced with.

MIKE: Amen. I've seen that be true over and over again. And I've seen some schools that focused a lot on skills say this, even something like a coding bootcamp. And this is not a criticism of coding bootcamps. They're focused on skills, right? They'll get you proficient in the skills you need to get going. But those concepts and fundamentals still have to be learned.

And the people who are very successful coming into software development through that skills-first approach take a lot of time to continue to learn those concepts as they go. There's a price there that must be paid. There's really no shortcut. You have to actually be seeking out, oh, what is, [chuckles] let's all say, Big O Notation? You know, how do I figure out how fast this algorithm works?

You know, it's something you probably weren't taught in your bootcamp, but understanding that some things go faster than other things [laughs] and learning to recognize the difference is going to be really important throughout your career. And actively seeking to grow your awareness of those concepts is going to make a huge difference.

DAVE: I had a really interesting epiphany about coding bootcamps. I think they're fantastic, but you have to know what they are. I don't really think of them as a way to jumpstart you getting going. They're a way to jumpstart getting paid. You can go from working at Walmart (That's what I did.) shelving product...and then, in my nighttime, I was, you know, doing everything I could to learn everything I could, but I was still working at Walmart.

And then I did kind of, like, a bootcamp induction-type thing. Back in the '90s, bootcamps weren't called bootcamps back then, but I did a thing like that. And it jumped started me into a programming job. I was still behind everybody. You know, I would go home and drink from the fire hydrant because I wanted to learn that. And so, the skills, the general concept knowledge, came. I had to fight for it the entire time.

But now I had cash flow, right? Now I could make my rent payment. And we live in the real world, right? Sometimes you got obligations that prevent you, you know, from going places you want to go. And having a coding bootcamp to say, "Oh, hey, you want to get out of that job and get into this other thing? Great. Here you go." But again, growth mindset. If you think the coding bootcamp the objective is to finish it and get a job, and now you're done, you're going to be back at Walmart next year.

MIKE: Yeah, I think that's well said. And again, this is not a criticism of coding bootcamps.

DAVE: It's also not a criticism of Walmart. That was honest work when I was doing that there. I'm just saying if you want to move into knowledge work, you have to recognize that your knowledge portfolio has a half-life of about 18 months. That's a phrase I heard, like, 15 years ago. It's probably shorter now. And what I mean by that is half of what you know to do your job will be useless to you in two years. I don't use Vagrant very much anymore. I use Docker.

And five years ago, I didn't use any container technology, and how much of what I know, right? You can pick any weird aspect of something. How much do you know about Chef and Puppet? We don't do that anymore, right? But it was an essential skill at the time.

MIKE: That just illustrates this vital importance of looking for those concepts, you know, and actively prioritizing some learning. One thing you mentioned there is you go home, and you drink from the firehose. I think that there is real value, real value, important value in taking some time outside of work hours to learn something beyond what you're doing at work.

I would say that most of my learning has been kind of the way that Kyle said, you know, at [laughs] work. There's a big pile of work, and you'll learn from it as you go. How could that not be where you learn most of what you know? Because that's where you spend your time.

Sometimes, in order to learn something new, something that you haven't done yet, well, you might have to do some learning outside of what you are paid to do because they might not be paying you to learn that technology. Now, it might go back and benefit you [laughs] in your career, even your paying career. But I do think that it makes sense to schedule some time every day, if possible, to learn something that interests you, you know, someplace that you want to grow your career, or, you know, just your skills, or even if it's something that's outside of monetary compensation. It's something you just want to grow in your abilities.

Take some time that you dedicate that's not even paid that you're just going to learn it each day, whether that's reading a book, whether that's taking a class. I do think that taking some of that dedicated time makes a really big difference over time. You know, it's probably not going to make very much difference if you do it for a week. But if you're studying for an hour a day, if you do that for a year, that's hundreds of hours. If you do that for ten years, it's thousands of hours. Thousands of hours of study in any topic is going to really push your skills forward. I would argue that doing something like that really matters.

Has anybody had a lot of success with having something to just schedule, whether it be a class, or a book, or newsletters? There's many different ways that you can get some of that information. What have you done outside of work hours to grow your skills?

KYLE: I thought about an example as you were talking. So, here at work, for my work environment, I work a little bit different than most of my team where I have a Windows box. And I would run a VM through VirtualBox, and I would use Linux on that. And I did that for two or three years with the newer releases of VirtualBox. And drivers in Windows, I was having quite a few issues with that.

And this is where I segue and say I'd gotten to where WSL 2 had come out. And on my personal rig, I'd been exploring that for quite a while, and just how seamless that was between that and Windows terminal, being able to use all the different terminal options, just from one window. And I know these things are available on other OSs, but I was stuck on Windows.

But I then utilized what I'd learned on my personal experiments and the transition from using a VirtualBox VM to using WSL for all of my work here. And I was able to dump that VM. In doing so, I have a lot more resources on my machine that have been freed up because I'm not running two machines, technically, now. So, that was just kind of an example I thought I'd throw out.

MIKE: It's one that I relate to a little bit. I used to always run VirtualBox as well [laughs] to run Linux. I had a work machine that didn't have it. And once again, you know, those experiments help. Thanks, Kyle. Anybody else have any experience with doing something outside of work that ended up providing a lot of benefit later?

SERGIO: I have something to tell you. I think the way I learn is by doing stuff. Yeah, for example, two years ago, I wanted to build my own house. So, I hired some people to make this happen. But in the process, I found I can design wood furniture, so I just started to design small things. I guess feeling that sense of accomplishment is what motivates me. So, when I feel comfortable, I end up doing nice things. So, I guess you need to understand yourself, yeah.

Something that I find nowadays, knowing smart people, makes you think, oh, well, it makes me think that I need to improve. Yeah, there is a good example in this company that I found people really smart, and see how they work, see how they do things. Yeah, it made me think I need to improve in some areas. That's something.

Also, when I was a teacher...I don't know if you know, but I was teaching in a university here in Honduras. I had this idea of make people live better through education. What I mean is, here in my country, there are a few resources. If you are a good teacher, you try to do your best to your students till they get or learn difficult things the best they can.

So, I guess something motivates people is, well, when thinking in the position of a teacher, yeah, I guess that opportunity to help people, and the people will understand you that you are really interested in they. It is nice for them to getting in shape really quickly on doing some stuff. So, I was a teacher from attending classes for software engineers.

MIKE: I think you hit something really important there. We're talking about how you learn something. We've talked about how we learn things on the job. And a lot of the reasons we do learn things on the job is that we're doing them, right? When we're doing something hands-on, we learn it very quickly, in a way that you just can't do when you're just reading about it or studying about it. Yeah, to your point, Sergio, you got to do it.

So, if you're really interested in learning how to do a new language, well, go and pick a project that you want to build and the language you want to learn and go start building it. And you'll learn far more building it than you would reading about that language. Not that you shouldn't do some reading, but the actual getting your hands-on, right? And working on it.

SERGIO: Yeah, I agree with that. Me working in this company is a real example of that. I don't know if you know, guys, I am being hired here without having so much knowledge about Ruby on Rails. So, I had to negotiate with me of the lack of knowledge that I have in certain areas. I know that I don't have to be perfect, but I made this negotiation and just keep forward.

Right now, I feel so nice with Ruby on Rails. I guess Eddy helped me in the process. Many people here is helping me, and yeah, that's awesome. But you need to understand...how much risk you are able to handle. [laughs] Yeah, it's [inaudible 30:45] in the professional environment, right?

MIKE: Yeah, you kind of tied several things together there that we've been talking about, taking risks, right? Being willing to get out and take those risks, getting yourself hands-on, but also getting yourself involved with mentors. You talked about, as a teacher, you know, really getting a lot of sense of reward in going and helping other people. That's so true. [laughs] It also is true when you are the student that you have to engage. There's a lot of reward to you personally in being willing to engage and getting those social engagements active, that when you do that, you tend to progress more than you would otherwise.

DAVE: I think there's a subtlety there as well, which is sometimes when we are trying to learn at work, right? We've got this key problem of, like, how do I get paid? How do I get my employer to be happy to pay me to learn this thing, right? And so, Sergio is coming in, and he's got to learn Rails because we're a Rails shop.

And, Sergio, there's something you did in your interview that convinced us to say, "Oh yeah, yeah, we're happy to teach you this particular skill because we know you can think." You sell your ability to think. You say, "Hey, I'm good at this general field," or "I'm bringing these other things to the table." And we're like, "Oh, we're going to have to teach you our database naming conventions anyway. It's just an extra couple of hours to learn how the Rails generators work," right? And down the road, you go.

It's really good to recognize, like, what skills you can bring that are, like, horizontal, like, wide-ranging skills that you can bring to the table, and they're going to apply everywhere. And then when you go to an employer and say, "Hey, I want to do this, and I want to use this specific technology," then the employer is like, "Yeah, yeah, I know you can get things done. Go for it."

MIKE: To maybe go back to the first story that I told [laughs] about my job where I really struggled with prioritization, in retrospect, I've learned when put in a situation like that, when put it in a situation where there's more to do than you can possibly do, it turns out that's pretty common in life if not the norm. You need to look at what needs to get done, realize not all of it is going to get done, and choose what you're going to work on each day. You need to make a conscious choice. There is going to be an endless pile of work.

And if there's an endless pile, it means you're not going to do all of it. You're going to be making choices, and embracing that choice means that you know you're going to work on this and not some other things. And it's very liberating to realize that, hey, there's this work I'm never going to get done, and maybe that's okay. And if that's the case, then it means that you can prioritize some things that maybe aren't quite as urgent but you know need to get done.

If you're feeling like you're not making very much progress in learning, in growing your career, well, maybe it's time to take a step back and look at those priorities and say, well, I'm not getting everything done. And maybe I would get more done [laughs] if I grew my skills in some way. If it's impossible for me to get everything done, then I shouldn't even try. What I should instead do is prioritize, work on the most important things first, and take some time to do something I really care about. In this case, take some time each day to learn something new, something maybe you're not going to do in your typical daily work.

Hopefully, you can do that at work. Hopefully, you can do something at work that maybe is from the other inbox, right? Some work that you're not usually doing because you can grow your skills there. That prioritizing makes a huge difference.

Secondly, we've talked a lot about social environments and how...with other people that can really help. I know that when I've taken classes with people, I finish, and I enjoy doing it together.

Finally, some people also brought up some really interesting ideas about being hands-on. If you really want to learn something, you have to pick a project and work on it so that you can actually have that experience rather than just kind of knowing about it at a distance. Also, about, you know, there's some talk about mentorship and that sometimes the best way to learn something is to teach. [laughs] And paying back is a really valuable thing to do as well.

KYLE: Just a thought I've had during this. Hopefully, the rain outside isn't terrible. [laughs] But I was kind of thinking, one thing that drives me that I've had to become okay with is the idea of imposter syndrome. I've ran into impostor syndrome, I feel like, for most of my career. And it has taken me a while to realize that's not a bad thing, and that's a driving point. And that is something that can keep you learning, and don't be afraid of it.

MIKE: Thank you. Talking about getting yourself in that uncomfortable situation, right? [laughs] Recognize that's okay, and that's how we learn. Thanks, Kyle.

I think that's a great place to end our discussion today. Remember, you're not an impostor if you're actually trying. An imposter isn't trying. If you're actually doing the work, getting it done, well, you're not an imposter. You're somebody who's there getting the work done. It's been great talking to you all. I've liked hearing all of your different perspectives.

We'll be here next time on the Acima Development podcast. Thanks.

Today's conversation delves into the multifaceted topics of learning, motivation, and engagement, shedding light on their relevance in both professional and educational spheres. The panelists scrutinize various job satisfaction elements, such as advancement, compensation, and engagement, with David notably challenging conventional wisdom on compensation, asserting that its importance diminishes once basic needs are fulfilled, and further arguing that increased compensation may actually hinder performance in cognitive tasks.

The discussion then shifts to the exploration of engagement, centering on the acronym NICU (Novelty, Interest, Challenge, Urgency) as pivotal factors for maintaining investment in work. David and Mark reflect on their educational journeys and the transformative power of innovative teaching strategies. They illuminate the nuanced balance between engagement and disengagement, investigating the subtle boundaries between motivation and procrastination, and examining how an overwhelming workload can erode one's connection to their tasks.

Transcript:

DAVID: Hello and welcome to the Acima Developer Podcast. I'm your host today, David Brady. Today we have a fun panel of Eddy Lopez, Ramses Bateman, and Mark Hymowitz on board. And we're going to talk about job satisfaction and what you can do to find a job that you're satisfied with or that you could be more satisfied with. And I have a lot of thoughts and opinions on this. And I'd really like to hear from some other people before I stand up on the soapbox and start preaching. What do you guys think? What makes a good job?

EDDY: We mostly try to figure out, like, what makes the job fulfilling for you, or, like, what do you like about the job?

DAVID: I would say that's the first question you actually have to answer, right? Because I've worked at jobs where I was working on bleeding-edge technology from the future. I mean, we were strapping hover boots onto the cow. It was awesome. And I've also worked on jobs where it's just knuckle-dragging, mind-numbing work that, you know, from enterprise stuff from 20 years ago and not solving any interesting problems. But, boy, we were making the company money.

It might surprise you to know that the technically challenging job was not very satisfying to me, and the mind-numbing job was immensely satisfying. I personally would say if we're going to talk about job satisfaction, I would say it needs to correlate directly to your happiness as a human being. Eddy, since you asked, basically, just for a split on that, let's start with saying what makes a job satisfying?

EDDY: Personally, I got to be able to see movement, if that makes sense. Like, the moment I become stagnant and I feel like I'm stuck is where I start to lose interest, right?

DAVID: Yeah.

EDDY: Versus if they tell me, "Hey, this is your path. This is your course for success," and I can work towards that path, to me, that gives me the motivation I need in order to push forward and do my research and become better at my job. So, as long as I have a path for advancement and not a lateral movement, I'm pretty happy about that. So that's my primary reason for job satisfaction.

A lot of it also has to do with, like, the work dynamic, the relationship between me and my peers, other sub-teams, you know, flexibility, time management, et cetera. But my primary one really is advancement.

DAVID: Yeah, no, that totally makes sense.

MARK: For me, I guess it would be to be able to look back and say, "Hey, this is what I've achieved so far." I like, for example, the Jira ticket system because it lets me kind of go back and see, wow, I've done all this over time. And I am achieving something every week or with every assignment. Doing a job where you're just mind-numbingly doing the same thing every day or seeing little results from it, for me, it's kind of off-putting. Being able to see that I'm growing and achieving something.

DAVID: Yeah, it's interesting to have, like, younger perspectives and older perspectives and to hear myself in your answers. I remember being very, very excited in my 20s to be working on just, you know, high-tech, just amazing, you know, crazy stuff. And I got really surprised by working on some jobs that were kind of cutting-edge, bleeding-edge technology, and I ended up very unhappy at those jobs.

I want to be clear here; the high-tech, cutting-edge was not what made me unhappy. Since then, I have worked on stuff that was just immensely fulfilling that was also, you know, new. But I was really surprised that I'm like, hey, why isn't there a strong correlation here between what I'm working on? Because I came out of there...the job that I'm thinking of, we were working on hardware. The NVIDIA GeForce had just come out, and I was working at a competitor company to them. So, people didn't know what the GeForce could do. They didn't know about hardware graphics acceleration.

And I was working at a company that made 3D graphics hardware acceleration back when nobody else was doing it. So, we were working on version 3.0. And it was an okay job. But it was, like, really, really disappointing when things folded up, and I, you know, ended up on the [inaudible 04:25]

So, the job that I went to after that, I ended up working in Java, which was not my favorite language. Java is very much a, you know, for me, it's, this is how we used to write software kind of language. It's like you're going back in time to pick up Java. Although, to be fair, this was 2006, and Java was actually, you know, fairly cutting edge. But I loved that job, even though I spent most of my job writing a database driver.

Like, we were writing a full-stack application to do, you know, travel reservations for people in high adventure, like, white water rafting reservations. Like, we could book you a seat on a raft that was going down the Colorado River. It was really kind of exciting, you know, kind of cool stuff.

And I was writing the low-level stuff to synchronize two separate databases to keep them in sync when they would be physically disconnected for up to 72 hours from each other. Like, you literally had people selling products out of the same database on two different servers that can't talk to each other because one of the databases is on a laptop up the river, literally up the river, with a paddle, with a whole truck full of paddles but no Wi-Fi. No way to get on the Internet.

And so, like, the river guide would jump on the river, and he's selling stuff to people, which I realize sounds really, really weird, right? But, like, people would show up at the launch spot and say, "Hey, do you have any open seats that we could get at a discount?" He's like, "Yeah, sure, not a problem." And so, he had to be able to sell that from his laptop.

So, I ended up having to synchronize databases that were, you know, disconnected for, like, you know, up to 72 hours. And it was the most fun I've ever had. It was just, like, grindy bit twiddling, you know, garbage coming in, writing our own read-write, you know, splitting adapter that would read from multiple, you know, multiple read databases but always send the updates to the same master if possible.

I don't know if it was mind-numbing, but it definitely...if it weren't mind-numbing...The other half of the application was accounting. So, we literally were writing finance tables, like, you know, credit and debit into an account. And what's the current balance? And what's the report for tax season? Another thing that a lot of programmers don't find, you know, exciting.

And I guess I will go ahead and spill the beans. I will let you guys know my secret, and that is there's a saying that you'll hear in this industry which is, "People don't quit their jobs; they quit their manager." And if you've ever had a terrible job and you think back to it, it probably wasn't the work that you hated. It was probably your boss or your boss's boss that you actually hated.

I've met people who cleaned out sewer lines, okay. Their job was literally to shovel crap, right? We joke about that; oh my, I'm just going to go shovel crap at the software mines. No, these people were shoving literal crap. And they loved their job because their boss knew this is hard, filthy, thankless work. And we are good people. We work hard, we get paid, and we go home. The boss took care of his people. And his people were like, yeah, the job stinks, like, literally, but metaphorically, it's a fantastic job. I love my job. And it's surprising to hear. Like, you're doing the worst job I can think of, and you're happy in that job? And yeah, yeah, they were.

So, I came across a piece of advice back in my late teens, which changed my world. I was about to head off to college. And this guy...I basically heard this guy talking. And he said, "If you have the choice between taking a super interesting class or signing up for the most amazing teacher that you've ever heard about, like, you've heard about the class. You've heard about the teacher, and that teacher is not teaching that class. You can either take the coolest class, or you can go with the coolest teacher."

He just hammered on the lectern and said, "Take the teacher. Take the teacher every time." Because a bad teacher will make that awesome subject terrible, a bad teacher will make you hate that awesome subject. And the cool teacher could be teaching, you know, basket weaving 101 or just the most mind-numbing, you know, dreaded, boring points of industry legal factions in 1600 Europe, right?

And you come out of that at the end of the semester going, oh my gosh, can you believe the legal implications of the 60 or 70 century Europe? And everyone looks at you like you're crazy because who cares? And the reason you care is because you had this amazing teacher. Oh, and by the way, you also got an A because you loved the work, and you got passionate about it, and you went nuts for it. And it's the people that you work with, not the actual work.

And I think a lot of people, when they're first starting out their career, they jump on the best work, and that's great. Like, if you don't know what to do and you don't know anybody in the industry, yeah, take, you know, take the most interesting work. But if you have the option to go to work for somebody who's amazing...and that job where I was doing database synchronization was the first time I'd worked with somebody who was the most amazing leader I had ever worked for.

Like, this guy he was not a good manager. He could not keep a schedule organized to save his life. But his leadership skills, man, we would crawl over broken glass for this guy just for the chance to lick a light socket for him. I remember telling him at one point...he was traveling on the road half the time, and the office was falling apart. And he's like, "What can I do to help you guys?" And I said, "Rodney, I don't know what you do here. I just know I need you here doing it because when you're here, nothing goes wrong, and everybody is happy. And when you're gone, everything goes wrong, and everybody is miserable."

Yeah, it was because he was just the most amazing leader. When he was in the building, you felt safe taking risks. You felt empowered to get something done. You could get meaningful things done; important things could get done. And, yeah, we were closing tickets left, right, and center when Rodney was in the office. And when he wasn't, every ticket seemed to grow new heads of, like, well, we solved this, but there's this edge case that we didn't consider.

And why a good leader made it so that tickets spawned more and more edge cases versus just closing them and getting them done, I still, to this day...I'm in my 50s now, and I still could not tell you why that happened. All I can tell you is that it did. And I worked for him for a year, and I had, like, consistent data. He would travel for three weeks, and everything would fall apart. He'd come back, and everything would get better. And then he'd travel, and it would all fall apart again. It wasn't, like, a sample size of, like, one weekend in November. It was a full year of this guy. And it's amazing.

So, yeah, if you have the chance to work on a great project or if you have the chance to work for a great team or with a great manager, take the people every time. Take the people. That's my big spill-the-beans secret for the podcast. So, I'm done. What do you guys want to talk about? [laughs]

RAMSES: In regards to this job satisfaction, one of the things where I feel satisfied about my job is, or most satisfied about my job, is when I'm learning something. I feel like if I do something for too long and I don't learn anything; I just get bored with it.

DAVID: Yeah, it gets mind-numbing, right? You're just, like, ugh. I've always been an autodidact, somebody who teaches themselves constantly. And I've literally had a boss tell me, "I'm not paying you to learn. I'm paying you to get stuff done." And I just had to laugh. So, what I did is I just made sure I was learning when he couldn't see me because every single week, he would sit down, and he'd say, "Well, I want you to do this." And he would name something that had never been done in our industry. Nobody knew how to do it. So, he was actually paying me to learn. I just thought it was ironic that he thought he wasn't.

EDDY: Yeah, that's me every day.

MARK: That's why we're working here. We're being paid to learn, and we're using our knowledge to build up Acima.

DAVID: Absolutely.

EDDY: I think what's also really important is having someone give you the patience, you know, that you need in order to get over the hump or something that you're stuck in. And I'm indebted to so many people [laughs] at Acima. It's insane. Like, I couldn't have gone as far as I have now had it not been for my peers having the patience and the willingness to help me. I think that's attributed a lot to my satisfaction here thus far.

DAVID: Yeah. I think I've said this before, maybe not on the podcast. But I've never seen a company with such an aggressive in-house career pipeline. Ramses and Eddy, were you both in customer support, customer service before moving into QA, before moving into engineering? Didn't you guys both come from QA or support into development?

RAMSES: Yeah.

DAVID: Yeah, that's rare.

EDDY: Not quite. [laughs]

DAVID: Not quite?

EDDY: Not quite. I'm almost there, but not quite.

DAVID: You're moving into engineering, correct?

EDDY: Yeah.

DAVID: Forgive me, I thought you were already here because of the level of competence that you have demonstrated and the amount of time that you spend, like, in the skills clinics class.

I've worked at a bunch of companies that tolerate the engineers doing a skills clinic, as long as it's, like, at lunchtime and not on the company dime, right? I've worked at a lot of companies that were like that. Acima is the first place I've ever worked at that said 10:00 o'clock every day, stop what you're doing, and go to skills clinic because that's the most effective thing we can do to get stuff done. It's not going to get the most done today, right?

And it's a 12.5% tax, right? I mean, it's one-eighth of your day, every single day that we're taking out of your work schedule. But we're banking on the fact that we can get 10 to the 100th power out of you a year from now. And it pays itself back in exponential dividends down the line, you know. Having somebody hang up the phones in QA for an hour, well, next year, we get that person as an engineer. And it's just the start because the year after that, we get that person as an intermediate engineer.

And five years from now, we get that person as a senior engineer. And all because we said, "Hey, why don't you sit down and let's learn how to write a web server, or let's learn how to use the SQL gem, or let's learn how to do, you know, this thing. Let's write a compiler for, you know, a couple of months." I just think that's amazing.

[crosstalk 14:58]

EDDY: I mentioned this, and I'm sorry if I put you on blast in front of millions of people that listen to this. But you were the very first person that taught me how to create a branch from GitHub.

DAVID: Oh, wow.

EDDY: And how to push it up. You legitimately spent, like, two hours walking through step by step on, like, how the architecture works using Git commands in order to get it up in the cloud. Like that, for me, I'm just like, oh my God, I have someone who's a senior developer in their own right, who's been in the industry for years, and he's spending an hour or two out of his day, you know, teaching me how to do a simple task, as simple as checking out a branch in GitHub.

Thanks to you, I had my very first branch created, and then, ultimately, it got merged. And I do want to say that that's paid its dividends because I've also helped other people interested in that as well.

DAVID: In defense of you, it did not take you two hours to learn how to create a branch, right? We dove in, and we explored this is how Git works. This is how Git thinks about your project. And once that light bulb went on, pulling down a branch, you're like, oh yeah, I can totally see. You had this mental model in your head of this is what GitHub is holding. This is what's on your hard drive. This is how Git's organizing. That's how Git is organizing this.

And creating a branch is how you just create a leaf on this tree. And then, you can move that branch up to here and the differences between merging and rebase. And I knew when I sat down with you that teaching you how to pull down a branch would be trivially easy once I explained how all of Git worked. [laughs] And I knew that showing you how all of Git worked was going to be the slowest way to teach you how to check out a branch, but, like you said, would pay dividends down the road. Because now we've got all the people around you know how Git works. And that's absolutely in your defense. Yeah, absolutely.

EDDY: Yeah. Yeah. No, I just wanted to make it known in case, you know, I've never expressed that. So, thank you for that.

DAVID: Thank you. I'll give you your 20 bucks after the podcast. Thank you.

EDDY: [laughs] While we were talking, I did look up an article online that gives you, like, a guideline of what topics make a job satisfactory. So, I was thinking maybe if we can go through that.

DAVID: Yeah.

EDDY: The first one is advancement, and I think we did touch on that. And I think I guess we can all just agree that a sense of advancement in a company gives you the motivation to continue. The second one, and I think it's just as important, is compensation. And I think that attributes a lot to people's, like, longevity for employment. Would you agree?

DAVID: How much time do we have? No, I don't. There's a whole slew of studies that have come out that basically show us that once you have enough compensation to pay your rent, buy your groceries, to live comfortably, and, you know, have just enough disposable income to not go crazy, compensation becomes one of the least important parts of your job. After you break out of the poverty line, compensation just becomes a score. And, yeah, it's fun bumping up that score. I got to be honest with you; I enjoy that. But it's so low on my feature list.

The correlation, however, or the other half of this, is that when compensation is not sufficient, it's the only motivator, right? You could have the best job in the world, with the best people, doing the most meaningful charitable work in the world, really improving the lives of humans around you. And if you can't make rent, you have to go flip burgers at McDonald's to make up that money. If you don't have enough money, it's the only motivator.

I will just throw this out for people that want to look at this; go Google Drive by Dan Pink. Google it or search for it on YouTube. There's, like, a half-hour version where he gives the full talk. And there's, like, a five-minute synopsis. There's a really good one (This is old, and it's going to date me.) where it's the YouTube channel where the guy draws on the whiteboard. And, like, he makes an animated sketch of the entire talk across the whiteboard. And if you find that one with Dan Pink's Drive, it's fantastic.

He gets into the other side of it, which is that they've shown that if they escalate your compensation in a job where you just have brain-dead physical labor if they increase your compensation, your output goes up slightly because you'll sweat harder, right? You'll knuckle down and like, ooh, I want that extra, you know, I want that extra bonus at the end of the day, and you'll sweat harder. But if your job is to think, the more money is on the line, the more stressed out you get, and the lower your performance becomes. And it's dramatic.

Like, if we say, "Hey, come solve this logic puzzle. If you can solve this logic puzzle in five minutes, and it's, like, one sentence or two sentences, so it's an easy solution, if you can solve this in five minutes, we'll give you $5." And a lot of people can solve it. And then they sat down, and I want to say they went to India, and they basically gave...I can't remember, but it was a lot of money. It was, like, two or three days' wages.

So, like, for us, it would be like somebody sitting down and saying, "If you can solve this logic puzzle in five minutes, I will give you $1,000." Now you're thinking about the $1,000 instead of thinking about the logic problem. And presto, you can't solve the logic problem because you actually need your full brain to do it. I will agree that if your compensation is insufficient, it's the only thing.

And I can also say I've worked at a company where I wanted a raise, and I felt like they promised me a raise and based on my performance. And, at the end of the time period, by every plausible metric, I had blown the doors. Like, my manager literally said, "You have blown the doors off of your performance review, drastically exceeds all expectations. Oh, but we recalculated the budget this year, and we can only give you a third of the raise that we promised you." And I was [inaudible 21:08] because I had busted my back because I wanted the raise, not because I wanted a pat on the back from this manager, but because I wanted the raise. And I didn't get the raise.

And over the next, I think, nine months, I kept pushing on my manager, like, "You really need to give me this raise. You really need to give me this raise." And he's like, "Well, we can't do it. We can't do it. We can't do it." And then I gave notice. I'm like, you know what? I'm going to go work...and I literally told him, "I don't have another job lined up. I'm just done working here."

Now, to be clear, I was really sick of my boss. I was really sick of his boss. And I was really sick of the president of the company. They were all very miserly. And they also had a lot of contempt for their employees. Like, it was apparent they were better than you; that's how they felt. And I turned in my notice, and my manager said, "I'll give you three times the raise we promised you." Just on the spot, like, I will give you a raise.

And, to be clear, we're talking about dimes and nickels here. The raise they promised me was 2,500 bucks per year, and they gave me a $1,000 raise. And he came back and said, "I'll give you a $9,000 raise effective immediately if you stay." And I lost it. I became absolutely livid. I'm like, "Rob, what you're telling me is that you've always had enough money to pay me what I wanted. And you just wouldn't give it to me. No. You have just doubled my reason to leave. I really just don't want to work here anymore." Then I walked out. So, yeah, compensation, eh.

MARK: It sounds like you experienced exactly what you were telling us at the beginning of this podcast, that you quit the manager and not the job.

DAVID: Yeah. I think we've beaten compensation to death. What's next on the list, Eddy?

EDDY: Yeah, the next one is engagement. So, what holds your attention? It keeps you invested while you're working. And some people attribute that to be just as important as everything else on the list that we've mentioned. And I think I've mentioned that too, right? Well, sort of. My job needs to continue to be interesting and challenging, or else I'll lose interest. Now, to be fair, personally, that's how it's always been since I started [laughs]. Like, I'm always being dealt with challenges, and it's great.

DAVID: Yeah, I learned a really great acronym, and I can't remember where I found it, and my Google-fu has failed me. So, anybody listening to this, if you find it, please contact us and let me know where you find it. But there's an acronym for things that engage us, and the acronym is NICU, like, natal intensive care unit. But, in this case, it stands for Novelty, Interest, Challenge, and Urgency. These are the four things that will get you out of bed running to your computer to get some work done, that will sharpen your focus, you know, to a razor's edge.

And we were talking about attention deficit disorder, which is something that colors my life excessively. I'll just say it that way. And so, I have to learn how to work with my strengths and not work with my weaknesses, or I get just destroyed. And people with ADD we are much more slave to NICU, to novelty, interest, challenge, and urgency. And so, if you don't have these things, you can disengage, right? And, yeah, if you don't feel like you're getting anything done, it can disengage you as well.

MARK: So, I think I can see that. During college, I was very disengaged with a lot of my classes just because of how I was taught. But then, like, outside the class, I'd be interested in basically the exact same thing, either by watching YouTube videos or doing [laughs] online challenges.

DAVID: Yeah, if this doesn't describe you, I'm certain everyone listening to this knows somebody who, the night before the end of the semester, the teacher basically, you know, grants a plea bargain to the student and says, "You're currently getting a D- in my class. You haven't turned in any homework. I will give you 70% credit for everything you turn in all the way back to the beginning of the semester if you turn it in before the deadline tomorrow." And then that person stays up all night.

I've been this person. I've been this person multiple times; I'm ashamed to say. Where it's like, oh, okay, yeah, I could not get engaged. I physically could not force myself to do the homework when it was assigned. But now that it's like, oh, I've got a D- and you're telling me I can raise this to a B+ by doing all of it overnight? That's urgent. That's a challenge. Now I'm interested, and now I'm engaged. And, yeah, you stay up all night just slaving away. And you have fun. You actually enjoy doing your homework, which is what the teacher wanted you to do from day one.

MARK: Question is, where's the line between you just not being engaged and when you're just being a procrastinator? [laughs]

DAVID: Well, for me, about 20 milligrams of Ritalin. [laughter] I'm kidding. I'm kidding. But Ritalin doesn't actually help. [laughter] It's a good question, right? If you've ever been in a meeting with me where we're talking about a subject or a topic, I will ask, like, really far-reaching questions about, like, who's using this, and what's important to them? And who's using their product, and what's important to them? And people are like, why does Dave care what's happening seven time zones away with people that are using this business that uses our product, you know, that we are writing?

And the answer is because once Dave can see where the software is going through the entire world and can see someone getting happy as a result of the lines of code that he writes, Dave gets really excited about the software. And he will stay up all night writing database splitters and grinding accounting code. And it's, like, programmers want to work on cool stuff, and that's, you know, we all talk about that.

But there's a dirty little secret of computer science, which is it's all cool stuff. The only thing that's uninteresting to me is when nobody cares when you write it and, meh, thanks, and one ticket moves. Or you don't even have a ticket, right? It's just like, oh, yeah, cool, meets the expectations. Ahhh, yeah, it's soul-draining to have that.

MARK: You've got me thinking now. I'm now remembering my high school math teacher who said all homework was optional. Paying attention in class was optional. You could be drawing in class or whatever. As long as you did well in the tests, in the final, he didn't care what you did.

And he made a habit of every 20 minutes in class; he would stop the class and say a random joke or go off topic completely just to make sure everyone was focused, engaged because he read somewhere that the average kid's attention span was 20 minutes. And, as you get older, that attention span starts to shrink. So, trying to listen to someone or teach someone something for longer than 20 minutes at a time, you need to give them a break. Otherwise, things start going in one ear and not the other.

DAVID: Yeah, totally. There was a professor at my university who did the most cunningly evil thing I've ever heard. He started class on day one, and he said, "I'm going to give the lecture, and I have inserted an error into the lecture. You get plus 10% to your grade...on any assignment you turn in, you get 10% extra credit if you can write the error down. If you can catch me making the mistake and write it down, and then correct the error, you get, like, this big jump on your grade."

And now, everyone is watching the whiteboard like a hawk, right? Just, okay, did he put all the, you know, pluses and minus? Okay, yeah, he did. The parenthesis are matching. Ah! There it is. He made a mistake right there. And you just, like, all the pens are like [vocalization]. You're like, oh, like, if you weren't paying attention, you're like, oh, sounds like he just made the mistake. I better check what's on the whiteboard, right? And now, even the people who weren't paying attention are paying attention. And it was awesome.

And the reason it was evil, I mean, it was genius to have done that to the entire class because he had so much more engagement as a result by putting in this challenge, this interesting challenge, like, interesting challenge, right? Also, novelty, right? Like, I've never had a teacher pull this kind of, you know, BS before.

The reason it was evil is the last week of class...this was calculus. And he ground into one of the really hardest theorems that we were going to try to understand. I want to say he was taking integrals of, like, trig functions. So you had to...we'd been thinking in differentials and changes all semester. And now we had to think differentials and changes in circles because we were working with trig functions, right? Things that go around and around.

And he went all the way through the whiteboard and through the class, and we couldn't spot the error. And so, we all had notes from everything he had written. So, we all went back. And we went through everything top to bottom, and we couldn't find the error. And, like, I went through my notes, like, three four times, and other people in the class, you know, multiple times. I went through my notes twice, let's be honest. I went through twice. I wasn't that dedicated.

But yeah, came to class to turn in homework, you know, the following two, three days, you know, the next day of lecture was, like, a Monday, Wednesday, Friday class. So, we come back in on Wednesday, and he says, "Yeah, so there was no error in yesterday's assignment. I just really wanted you guys all to study the crap out of differential on trig." [laughter] And it worked. And we all did it. And --

EDDY: That's --

DAVID: We laughed, right?

MARK: He played you guys.

DAVID: Yeah.

MARK: He played you guys. [laughs]

DAVID: And I got 100% on that part of the test, and I did really well on the rest of the test because of how he'd done.

EDDY: He found a way to engage you. And I think that's key, right?

DAVID: Yeah.

EDDY: I think there's a thin line between engagement because there have been times or situations, personally, and I think maybe some people can relate where, like, if you feel overwhelmed taking, like, a task, right? Like, your engagement slowly goes down, right? Because you see no purpose. And that's part of the reason to why, like, a teacher or a mentor is really important if done correctly because even if you hit those bumps, there's just methodologies on getting unstuck, right?

DAVID: Yeah.

EDDY: I actually wanted to say something that's kind of interesting, kind of, like, as a side topic to that. And I think I had a professor in college who had, like, three classes, and, like, his attendance for each class was, like, 15 students, a little over. And it was English, and, to myself, I was just like, there's no way this teacher reads all these essays. And, like, these essays we were turning in were, like, 15 pagers, front and back. And I'm just like; there's just no way he reads through everything, right?

And so, like, one of his assignments somewhere in the middle, I tried to be funny. And I was just like, if you read this sentence, I'll buy you a pizza. And I continued with my research, right? And a couple of days pass. He's handing them out. And he hands it to me, and he's like, "What do you know?" He's like, "You owe me a pizza." He continues. [laughs] And I was in awe, right? And I gave him his pizza if you're curious. But, in reality, I was just like, wow, wow, right?

DAVID: Yeah. And what's the message there? The message is, Eddy, you are important to me. And that's why I'm paying attention to what you're writing, right?

EDDY: Yeah.

DAVID: It's not that I paid attention. It's not that, oh, I'm a good teacher. Look at how clever I am. It's, you're important to me.

MARK: Now give me the damn pizza.

[laughter]

DAVID: Yeah. Now give me the pizza. Yeah, right? [laughter] And now, helping you be honorable and fulfill your commitments is important to me, too, so give me a pizza. [laughs]

We are getting close to the top of the hour. Do you want to just burn through the rest of the list?

EDDY: Sure. The other ones are flexibility, proficiency, security, teamwork, and value.

DAVID: Nice.

EDDY: Yeah. And I think all those are pretty strong [inaudible 33:41] in their own right. We can even enlarge that and make it its own topic, honestly.

DAVID: Yeah. If you go check out Dan Pink's Drive, he gives, like, four or five things. And there's a really strong matchup, like, the ability to get better at a hard thing; mastery is what he calls it. But that's, you know, challenge, and proficiency, and engagement, right? The ability to get better at something and to be recognized for getting better. Yeah, it's well worth the read.

It helped me understand...I had...the year prior to Drive coming out or two years prior, I had taken a job. I was already in the industry. But I was making pretty poor money. And I got a job making double. But, I mean, I was already, like, a salaried software engineer. Making double was big money for me. And I was working for a lawyer who was, in hindsight, a psychopath. Like, I genuinely believe the man was a psychopath. He liked making people suffer. And I quit that job after, like, three months.

I lasted a very, very short time at that company because this guy would come in, wind me up, and piss me off, and scare the hell out of me, and then giggle and walk off. And I'm like, no. No amount of money is worth this. And it literally...I went back to, you know, about half of my salary. And I was making money in the 30s. So, you know, the job working with this guy was in the 70s, which, 20 years ago, again, big, big money, especially for Utah, right? Where the, you know...

And my wife, I came home and told her I had quit my job, and she's like, "It's about time." I'm like, "What?" She's like, "You have hated this guy since, I mean, this guy has just made you miserable. And you have been miserable to be around as a result. So, yeah, it couldn't happen soon enough." And I'm like, wow, okay.

We are out of time. Thank you very much. This has been a lot of fun. And I hope to see you guys next week.

This conversation explores various coding strategies, the role of AI tools like ChatGPT, and the handling of legacy codebases. The panelists share their methods for understanding code, including the importance of struggling with code for deeper learning, and raise concerns about future dependence on AI and its potential impact on coding habits. The conversation also emphasizes the art of reading code, the importance of recognizing and learning from quality code, and reflects on the joy of reading well-communicated code.

Transcript:

TAD: Hello and welcome to the Acima Development Podcast. My name is Tad Thorley, and I'm hosting today for the first time. We also have a whole host of guests today as well. We have David Brady.

DAVID BRADY: Howdy, howdy.

TAD: David Solano.

DAVID SOLANO: Hello.

TAD: Eddy Lopez.

EDDY: Howdy.

TAD: Matt Hardy.

MATT: Hello there.

TAD: Mike Challis.

MIKE: Hello.

TAD: And Sergio Peralta, who's also new.

SERGIO: Yeah, I am new. Hi, guys.

TAD: Our topic today is, how did you get up to speed when you're starting with a new codebase? Also, with that comes along the idea of working with legacy code. One thing I was thinking I'd start with is maybe focus on a Rails project because I know we all are familiar with Rails, and then maybe expand that out to just codebases in general. My first question for you guys is, when you start brand new with a new Rails codebase, what is the first file that you think you look at?

MATT: I'm going to say the gem file.

DAVID SOLANO: Me too.

TAD: Cool. What does the gem file teach you?

MATT: By looking at the gem file, you can see some of the project's dependencies, some of which you may already be familiar with. And that can really help you learn your way around a project, just knowing the tools that are being used inside of a project. For instance, if I look at a gem file and I see Grape API in there, I know where those endpoints are going to be, and I know how they're going to be structured, right?

TAD: Right. I think it's interesting. You can often see, like, Ruby version; sometimes people will put it in a gem file, internal gems.

DAVID BRADY: I was going to comment that I have a weird answer to the what file do you start with? And the answer is no.

TAD: [laughs]

DAVID BRADY: My favorite place to start is by pairing up with somebody and having them show me the app so that I know what it does. And then, like, very, very quickly, somebody who will sit you down, and they'll say, "Okay, let's go here." And then they will casually mention offhand, you know, "Oh, this whole section is generated. It's just static. It's generated by Jekyll." And I'm like, ah, okay, I know where all of this section comes from.

After I pair up with them or while I'm pairing up, I will often pull up the directory listing of the root of the project and often app models and app controllers. And I'm trying to come in very breadth-first, very top-down. So I can work on a project for a day or three without ever opening a source code file to look at it but probably because I'm a bad programmer. But I like to get the layout of the forest before I, like, take a core sample out of a tree. Does that make sense?

TAD: Sure. Yeah, [inaudible 02:57], right?

DAVID BRADY: Mm-hmm.

DAVID SOLANO: I [inaudible 02:59], David. I pretty much do the same. But if you ask me to look, like, one file kind of just to have, like, a quick look of the entire project, I will say a gem file, but I'll also take a look at the application controller. And you'll see some weird stuff happening there.

TAD: [laughs] Yeah.

DAVID SOLANO: I'll give you an idea. Like, I remember one time I saw it, and I saw an application controller from really old code, right? Like legacy. I don't know; it was like 3,000 lines. [laughs] So it was pretty funny at that time, right?

TAD: Well, it's interesting to see some of these, like, grandpa classes that everybody's going to be inheriting from because, a lot of times, there will be behavior that's happening there, maybe like a before filter or an after something going on that is always happening, but you don't realize it because it's kind of tucked away.

MATT: Yeah, I think Dave brought up a very good point, though, if possible, the most important thing is let's look at a running version of this application and have a tour of the UI. You know, you can learn a whole lot just by seeing the UI of something. You get a feel for how it works.

And then I also really liked how he said top down. If I'm going to get into the code and look at something, the first thing that I'm going to look at are the endpoints, right? Because that's the entry to everything. And I think if you can track down the proper endpoints, you can find your way through the entire integration of that particular feature.

TAD: No, I agree. Finding kind of the entry point into the code is really valuable. And the parts that you present to people are probably some of the more important pieces, right?

MATT: Absolutely. Any transformations that happen can be tracked down as long as you can find your entry point. I mean, with modern IDEs, it's pretty easy to navigate your way through code and kind of fumble your way through to see where things happen.

DAVID BRADY: I think it might also depend on your team style as well. Like, I will often open a project and like David was saying, drill into, like, the applications controller, but I will do it, like, dynamically. I'll just go to the project and do Rake routes and say, okay, you tell me where these things are coming from. And that'll show you things that are mounted in the app directory that aren't in the app controller. They're brought in from somewhere else, and that sort of thing.

But it'll also show you in a hurry if the team cares about what the Rake routes thing returns, right? If you get 700 lines of RESTful routes and it's just create-update-edit, create-update-edit, you know, da, da, da, you know, over and over, no, no, you're just like, uuh, okay, all right, [inaudible 05:50] [laughs] to do this. But if the team does care about it, if it's, like, maintained and very, very careful...which actually dovetails on to the next idea, which is the next place that I will check is I'll try to run the spec suite.

And you very quickly find out if the team is writing specs, like, after they write the code, if they just try to bolt down the edges of their features, or if they started with the specs first and said the app should do this. And now when you open up the spec file, it says, oh yeah, the app does this, and it does this, and it does this. And you drill under that [inaudible 06:19], and it does this way, this way, and this way. And you could really see that. It's almost like recognizing handwriting in the code.

And that goes into, like, gathering the lay of the land on a project. You very quickly pick up, okay, that developer is very terse and very direct. And this developer is very verbose and nuanced. And it changes how you pick up their code and how you follow their breadcrumbs.

TAD: Right. I still remember I was on a team, and one of my co-workers asked me, "So, what does this feature do?" And I said, "Oh, well, I wrote a bunch of tests." I told them where the tests were. And he's like, "No, I don't care about the test. Just tell me what it does."

And I was kind of dumbfounded because, for me, the tests are telling me what it does, right? Like, that was the obvious place to learn what something does is by going and looking at the tests, but his approach was a little different, I guess. And it sounds like you're kind of the same way, Dave, where you would love to see some good tests to really get a grasp of what's important, what people's styles are, what it does, right?

DAVID BRADY: Mm-hmm. Absolutely. At risk of ending up on a soapbox about specs—and some of you have been to conferences where I've really gotten on my soapbox—there are multiple audiences for testing. And a lot of people don't care about the first two audiences. And that ends up creating low-value tests, which is sad because the reason they don't care about those first two audiences is because they've been brutalized by low-value tests, and it's a vicious cycle. You write them bad; you get them bad.

But the first two audiences of a spec file is, if I pull down the app and run, you know, migrations and boot everything up, I want to run the spec suite. And I don't want to have a conversation. I just want a green dot or a green okay. Does the app work? Does it take over? After that, the next bit of audience is, if I'm coming into a piece of code that I have to maintain, I will go to the spec suite and say, can you tell me the story of this? What does this code do? What is its responsibility? What's it [inaudible 08:20] Don't tell me how it's doing it, just tell me what it's trying to do.

And then do I care about drilling in to say, you know what? How does the API work? How does the code work, and what are the implementation details? And if you care about those first two audiences and getting those things airtight, the spec suite will get your back later on. And, yeah, when you come into a team if...and this harks back to what I just said about, you know, the team style. If the entire team doesn't care about the test suite, the specs won't get your back, right? They'll be very sparse, and there'll be lots of gaps. And, you know, you come behind and do your best to preach in the wilderness, you know, to repent and write better specs.

TAD: To further your point, Dave, you'll know which flags they use when they run their tests even?

DAVID BRADY: Yes, right?

MATT: Thanks for saying that, Dave. Because I think something that really helps define how I would look into an unknown codebase is team culture. Any of us who have been in this industry for a length of time we've worked in codebases where there aren't any tests, where that culture isn't there that people want to help you out.

If I walk into a great culture like we have here at Acima, the first thing I'm doing is I'm pairing with someone. And they're going to walk me through the code, and they're going to lend me some assistance. And they're going to explain how things are tested, and why we test, you know, and the importance of those things. And I think culture has a really big role to play in this.

DAVID BRADY: 1000% to that. I moved last year from the Atlas Team over to the Data Services Team because I really wanted to get into big data. And one of the things that surprised me is that our process over on data services is a little bit old school. It's a little bit enterprise. It was where software development was in, like, 2005, like, pre-agile. And I'm not saying that to criticize the team. It's just that's just, like, the way the culture here works. So we don't use tests.

Developers work alone. They want a quiet office so that they can think and get really, really deep in the code. That creates some artifacts, right? There are files in the codebase that have been abandoned for three years. And you have to know when you get into a file, oh, I need to go check git. This is not even, like, an indictment of my current team, and I don't mean it that way at all.

You have to come to the team from their culture, right? You can come into a piece of code and go, this makes no sense. How does this ever...oh, wait a minute, git log. Oh, this was last tested in 2017. This is probably not current code, okay, cool, fine. And then, you can pick it up and move to the next piece. And you run into a piece of code, and you're like, how the heck does this work? And you have to, instead of saying, well, the Atlas team, I would expect a very shallow cut, a very quick test, a very high-level, you know, break this down just this one piece, [inaudible 11:14] detach this and run it.

But on data services, I expect a data warehouse to be present. I expect a lot of, like, very expensive dependencies to be present. I expect to lean on those very, very heavily. And so, I'm not expecting a small cut. I'm expecting to pick up this entire ETL file that transforms the data out of the merchant portal database and moves it into our data warehouse. I expect to pick up that entire chain and hold it all in my head because, remember, we are working...we're not pairing.

We're not doing any high-bandwidth communication. We're doing slow, deep thinking about how we work with the things, and that really, really dramatically affects, you know, what direction the code is going to be in. I'm not going to go look for a test. I'm going to dig into this file, this file, and this file because we have a working template of how these three files always fit together.

TAD: Yeah. We've heard from probably, I'd say, some more of the senior folks on what they look for and what they do. I'd like to also hear from our newer folks. Eddy, when you get a new codebase or you're exploring, what's your approach?

EDDY: To give you a bit of perspective, I want to premise saying that I only got about a year and a half of experience total, and I probably went on it the wrong way. I didn't ask the right questions. I was just too eager to pick up, like, tech debt tickets. And so, I got familiarized with the code by picking up work that didn't have as much attention. And I slowly trickled my way through the whole codebase based on my necessities.

In hindsight, that's probably, like, the wrong way to do things, at least to me with having a bit more wisdom, not a lot but having a little bit more. Seeing other people's approaches to tackling new codebases is amazing. Like, you, for instance, made a comment about I like to look at the biggest file. Like, so if you look in the app directory for models, for example, the biggest contender for that was lease. And you're like, huh, Acima does leases.

And I think, for me, that would have been something to truly understand before I even picked up any changes because, in order for the changes that I'm implementing to be efficient, I also need to understand at the core what the app is doing. And that was my biggest fault when I first started.

So I would say grasping the fundamental core of what the actual app that you're developing for does. And one thing that really solidified that for me was running the app as an end user. So I played around with it, played around with the functions. What am I able to do? But you mentioned something really important that I've done without even realizing is ask for help, right?

TAD: Nice.

EDDY: Asking my peers what their experience is like with the code changes that I'm supposed to be making and have them just take time to really drill that in my head. I think that's really helped me out a lot.

DAVID BRADY: I just want to back you up, Eddy. I don't think you were wrong with your initial approach, like, jumping in, grabbing, like, a corner case ticket or a weird, you know, bit of abandoned work. First of all, that's proactive. You're not on your back foot waiting for your manager to just throw stuff at you. You're actually, like, going in and saying, "What can I go get?" And that changes your attitude.

And then the other thing is you would pick something up and try to figure it out. And one of the most powerful things you can do is just grab one piece of data and follow it completely through the system. Like, from the moment a user typed it in on the web page to when it ends up in the accountant's reporting spreadsheet, how did that get through the system? And knowing all of those pieces. You have to string all of the beads onto the string that represent the app. And that is super powerful. It gives you a ton of context.

DAVID SOLANO: It's also [inaudible 15:07], for example, so you receive, like, some ticket with a new implementation. But maybe no one knows how to get that calculation right. But you know that your PM or someone else knows that that's reflected somewhere in the UI. And you know that if you go to that specific part of the UI, and you find that number and say, oh, hmm, here it is. Now you follow back to the code, to the back end. And then you know, oh, this is how the way it works. And if you're able to follow that approach also, that's a good way to do your work, to come to the idea on how to solve this because you already...you were able to follow it through the UI and through the end code.

TAD: I think it's interesting that there's different approaches. And I don't know that certain approaches are necessarily better than others. And sometimes it's just, like, the approach that works for you given your current familiarity, experience level, that kind of thing. Sergio, I'd like to hear from you because you've recently joined the team. And you've had to do this where you came in, and we said, "Here's a codebase. Figure it out and go." What did you do, and what was your experience?

SERGIO: Yeah, yeah, I have a nice history behind this. Like, I don't have a very big experience with Ruby on Rails. I am coming from another stack. And I am facing two different things; one is lacking the knowledge of Ruby on Rails in some things, and also the lack of the knowledge of the business rules behind, and the legacy code, and the [inaudible 16:43] of code.

So my approach right now is, yeah, seeing that unit testing, getting a know of how the application works. I've talked with other people about if they have this kind of issue before and also with most experienced people about how to do some specific things. So, yeah, what I can tell is, like, I am the kind of people that like to learn myself is, like, trying to figure it out by myself.

If I don't spend enough time to try to figure it out by myself, I guess I don't move in the right path. It is like having someone else telling you how to do it step by step is good. But, at least for me, I need the time to process myself and figure it out myself and struggle with some stuff, then continue with the role. That's what I do usually. But it is, like, the way I learn. So that's the thing I can say.

TAD: I think that's a fair point because definitely, the code I've thought about and struggled with is the code I remember best, right?

EDDY: I want to really fixate on what you just said, Tad. Holy cow that resonated with me deep down. The tickets that I particularly struggle with the most are the ones that not only grow my skill as the developer but also, like, really drill down [laughs], you know, for my fundamental understanding of that particular code change that I'm making. I also want to say thank you, Dave, for reaffirming my path initially for merchant portal's codebase.

DAVID SOLANO: Hey, guys, I don't know this...this is out of topic. But right now, I am using this ChatGPT tool in some cases where, hey, what if we can improve this code? At least for me, I don't have the sense that the code is wrong. But I just paste the code, check what ChatGPT is thinking, and just let's compare it with my notes and see if the things are good or not.

Yeah, sometimes, yeah, I got nice answers, sometimes not, even the code doesn't run. But I like it. It's a tool that is helping me in some stuff, maybe when I feel stuck with something. But, yeah, just to mention. I don't know if it's out of the pocket but yeah.

DAVID BRADY: I've played with ChatGPT as well. And the thing I love about asking it to write your code for you is not that it's going to write the code but that it will say, "Okay, well, here's a block of code." And then, in plain English underneath the code, it starts breaking down the code that it just gave you, and it says, "Okay when I do this, it's setting up this kind of a thing. And then I'm going to do a double dispatch into that. And then I'm going to do this, which is going to set..." And it walks you through how the entire thing...

I asked it to write a really weird SQL query. And it gave me a SQL query and then broke it down and said, "When I use this window function, I'm going to get this, and then when I do this, I'm going to do a subquery." I'm like, holy crap, that's awesome. Yeah, I like the explanations that it gives.

[crosstalk 19:58]

TAD: It seems like pure programming but just with a bot instead of a person, right?

DAVID BRADY: Yeah, yeah.

EDDY: I've had ChatGPT breakdown code in certain aspects. And I'm like, huh, I don't really understand what this method is actually doing. So, like, I've copied and pasted in ChatGPT. I'm like, can you break down in layman's terms what exactly this is doing? And it kind of follows the same thing that Dave said where, like, it adds comments, you know, to each line of code and tells you, oh, this is what this does. This is what this does. This is what...I was just like, oh, interesting. I did not know Ruby was capable of such things.

DAVID BRADY: I had a fun...it's a little bit off-topic, but it gets more into the ChatGPT thing. The other thing I like about it is it really does act like a pair. I asked it to write a bit of code, like, a Bash prompt for colorizing some things. Who keeps ANSI color codes memorized, right? And it came back, and it said, "Well, you can do this." And it gave me the ANSI color codes for the thing that I wanted. And then it said, "That works because this, this, and this." And it was wrong, the explanation. I mean, the code was right, but the explanation was wrong.

And ChatGPT it's read-only in terms of the big brain. Like, when you finish a conversation, nobody can use the contents of your conversation. It's not modifying and updating the AI. But in the context of the conversation, it will act like a pair programmer. So I actually...I went, "Close, that's very good, but this is wrong." And I told the bot, "This is wrong. This piece actually means this, and this other piece means this thing."

And then, because it's a bot and because it's AI, I said, "Would you try to explain it again?" And it gave me the code and the explanation again, and this time it was perfect. It said back in its own words what I had just told it about the code. I thought that was mind-blowing. Really great. And a good way to think, again, like a pair programming partner.

TAD: Well, I thought it was interesting, Dave, that you pointed out that maybe step zero is not even read the code; get someone to guide you through the code. And it sounds like ChatGPT can kind of do that, right? Like, it can serve as a sort of guide as you're trying to understand a new codebase.

DAVID BRADY: Yeah, it's going to give you what we're trying to accomplish along with the how we accomplish it. Yeah, it breaks it down at both levels. It's really neat.

EDDY: Not to mention that ChatGPT is almost always available for you to pair versus asking someone else on the team who might be busy.

TAD: Do you think we'll see more tools like that integrated in the future? I mean, we already have some pretty powerful plugins and IDE support and things like that for understanding the codebase. Do you think we'll get kind of cyborg-guided things as well?

DAVID BRADY: I think it's inevitable, yeah.

MATT: Yeah, I think --

DAVID BRADY: Everyone's afraid that, oh, the bots are going to take over my job. No, they're not going to take over your job. But your job in five years is not going to be to punch in all of the codes to create a Rails route in a back-end controller. In five years, the most effective programmers are the ones that tell their IDE, which is backed by AI, and say, "Give me this resource controller [inaudible 23:08] connected to that." And the AI goes da, da, da. "On this one connection, did you mean this or that?" "I want it that way." "Okay, cool." And it'll spit it all out.

The people who can operate the high-level machines the best are the people that, you know, will have the best jobs in five years. And it's exactly the same way as we are. You go back 25 years; people were running...well, 35 years, people were writing code with text editors, with dumb text editors. And then IDEs came about, and our job now is to know how to run more and more sophisticated IDEs. I think that's inevitable, yeah.

TAD: So your argument would probably be, when you first start, like, you were talking about meeting with somebody who could give you a tour of the overarching ideas, point out the different pieces from kind of the higher level thing. And it sounds like you're saying that's probably not going to go away, that you're still going to need to have someone that has an understanding of what needs to happen, what all the pieces are, and that kind of thing. But those pieces are maybe going to be, you know, bot-augmented, rather than you hand-code all of them.

DAVID BRADY: Yeah, 100%. There's always going to be a market for somebody thinking. There is a fantastic quote that I saw about 25 years ago. I can't remember who said it, but the way they phrased it was no amount of best practices, industry-sophisticated tooling, or agile, or otherwise processes can take the place of knowing how to program a stupid computer. And I think that will continue to be true where the term program a computer is slowly turning... it's no longer dropping, you know, bit one, bit zero, bit one, bit zero into the CPU. Now it's more and more tell me how you feel, and I'll write an app.

TAD: So one of the interesting things that was mentioned is, as you look through the code, you can kind of see people's signatures, so to speak, on different parts of the code. Does that become more consistent? And if the code becomes more consistent being generated by a tool, does that make it easier for a tool to then understand the code?

DAVID BRADY: Ooh. I think the second half of that is going to be really hard because I think the first half of the question of does it become more consistent? I would say it depends on your team. If you're doing very high-bandwidth, high-pairing, lots of retrospectives, lots of communication, then, yes, the code is going to homogenize as everybody cross-pollinates, you know, best practices, you know, between each other.

Where the team that I'm on, which is involving a lot of really, really deep thought, I have found really clever tricks that my co-workers have done in the code, but they're down in the code, and they're undocumented. And when I go into that person's piece of code, I will copy that trick for the next piece because it's consistent with their style.

But when I then move from that person's code to another person's code who doesn't, it's clear from the context of the code that this person's skill set is way, way powerful somewhere else in the code. I try to copy that, but they don't understand that trick that that first developer was doing. I won't copy that in because that second developer is probably going to come back to this piece of code and maintain it. And I don't want to trip them up.

So maybe, you know, maybe in, you know, 5 or 10 years, the bot can basically step in and say, "Okay, yeah, this team has a highly fractionated, you know, highly speciated personalities in the code." I've had long conversations with my boss about "I got some code, and I think it was written by this guy, Zack; just look at the file anyway." "Yep, that's him." And, you know, and we had a laugh about that person's style.

And I think early cuts of the AI are going to make the mistake of thinking that there is THE way to do it. And later, more and more sophisticated versions are going to recognize that, oh no, there's a bunch of different ways to do it, and some of them are more appropriate to the given situation.

EDDY: I kind of want to add to that if that's okay. The skills that I've learned so far have been with me stumbling upon the answer, right? Reading up on documentation about someone who ran into this problem once before and explaining the solution to how they got there. The reasons why I was able to remember those solutions so well was because I landed on that after probably half a day or a day, you know, for a solution that was so simple.

I'm afraid that if we start relying a bit more on AI services that are just spoon-feeding our answers to our questions almost immediately, I feel like that may create bad habits in a sense and, therefore, like, losing retention on that answer, right?

TAD: I think it's --

DAVID BRADY: There's a really fantastic book from about 20 years ago called The Pragmatic Programmer. And one of the chapters in the book is called Don't Trust Evil Wizards. And back in, like, Visual Studio around Y2K era, there were wizards that you could run. It was like a, you know when you do Rails scaffold, and it will generate the scaffolding for you. The wizard would do this.

It would write a whole bunch of really deeply nested, complicated C++ code for you. And it would wrap it up in macros, and you never really needed to know what those macros did until you did need to know it, and then you were screwed because you had no idea how the wizard was doing it. And that's an evil wizard.

Like, a good wizard is somebody who's going to, you know, scaffold out your code and then leave it all very clearly documented at a very high level. And then, yeah, you have to come back and follow through and understand what the wizard was doing for you. You don't want the wizard...and I realized that with AI being, you know, intelligence being the I in AI, you don't want your wizard to do your thinking for you. And that's the danger of AI is it really feels like it's doing thinking for us.

And the first people to really leverage AI will be the ones who know how to constrain its thinking into the things that we can understand and maintain so that if we move outside the AI's, you know, knowledge or, you know, the power [inaudible 29:21] for that tool, that you're not left high and dry with wondering, well, how did it build this great, big, black box? You're like, oh no, I've got all the pieces. I can modify this from here.

EDDY: Or what happens if you get...you're so acclimated to use a service that spoon feeds you, and then, all of a sudden, that service is down because that's inevitable, right? Services go down all the time. So, what are you going to do in that point when you're in a pressing...a time constraint, and you're like, oh, I really need to get this done? And, all of a sudden, the tool that you rely on isn't available.

DAVID BRADY: Yeah, it's the 3:00 a.m. fire, right? Like, okay, it's just me, eMacs, and a server that's on fire. How are we going to get through this, right? For everyone else on the team, step one is shut down eMacs and start-up Vim. But I get it.

DAVID SOLANO: Hey, Eddy. I have my thoughts about what you mentioned of bad habits. For example, look back in the past, in the '80s, when everyone who wants to make a program have to do Assembly coding. And right now, [laughs] it's nearly impossible that some of you guys use Assembly to write a program. So, yeah, it's like the technology is changing, and we are changing with this. And probably, I don't know if in the future we will be based only on the IA, so... AI, sorry. [laughs] But yeah, that's the point. It's like everything is changing. And probably all our habits will change with the tech.

DAVID BRADY: I think so. I worry that we're getting off-topic of tearing into legacy codebases. But I realize I'm the problem as well as the [inaudible 31:02] concerned about it. But, yeah, I am the source of most of my problems. I wanted to shift a little bit to talk about a couple of resources that I have used for maintaining older code. Is now a good time to do that?

TAD: Yeah, I think that's great.

DAVID BRADY: Okay. I think most of us have heard about Working Effectively with Legacy Code. It's a book by Michael Feathers. And it's still the gold standard, in my opinion. He talks about, like, when you get a gigantic legacy codebase, what do you do? Like, when you have this big chunk of untested data with this hideous dependency, how do you dig into it? And it's a little bit like the old refactoring book where he literally gives you recipes, right? If it's this, you need to do, you know, extract static method, or you need to change the parameter of this but try to maintain the signature and that sort of thing.

There's another book, though, that I think is this beautiful, beautiful gem. It's called Code Reading. And I'm going to mangle this guy's name, Diomidis Spinellis, I think is his name. But Code Reading is a book about reading code. He starts with the argument that every other creative endeavor that you go into, an engineering class or anything, the first thing they do is they sit you down and they make you study the masters. And, like, if you take a painting class, the first thing you do is copy different paintings in different styles to learn these artists' styles so that you can develop your own style.

But when we teach software, we tell you plagiarism will get you expelled. Don't even look at anything outside of your paper. And that's crazy because when you get out into a career, your boss just wants the website to process a credit card. You know, she doesn't care if you wrote it all original code or if you had an AI, you know, spit something out. It doesn't matter. We just want it to work.

TAD: Or Stack Overflow, right? That's --

DAVID BRADY: Yeah, Stack Overflow.

TAD: [inaudible 32:48] Stack Overflow exists.

DAVID BRADY: Yeah. And so Code Reading is literally a book on how to develop the skill of reading code. He makes the pretty bold argument that open source is just a godsend for us. He's like, yeah, you probably want to learn C. Now, this book is 10 or 15 years old. But he's like, you probably want to learn C because, like, if you learn just enough C to get around, you can now read the entire codebase of Linux and all of the tools that are in Linux because the source code is in C. And holy crap, right? It's like, you want to figure something out.

And he throws a wild curveball, like, in chapter three or four. He's like, okay, write a program to calculate the date of the next Easter. You have one hour, go. And, okay, hang on. Easter falls on the first Sunday after the first full moon after the spring equinox. Oh, good luck, right? And he walks you through how you can solve this in 15 minutes if you know that Linux has a bunch of calendaring apps. And there's a function down in there called POTM, Phase Of The Moon. [laughs] And it will let you calculate what is the next full moon going to be? And it's hyper-accurate, and it works. I mean, it's good enough for the operating system.

And you have to be able to surf into a million-line codebase and find the piece that you need, and then read that code in high detail and go; it's this. This is the math, and then this is the offset, and this is the thing. And you're like, okay, cool, and down the road you go. And you can build it out, you know. And that, I think, was a really, really good thing because he talked about the necessary grammars and patterns that you want to develop.

Tad, you mentioned at the start that, you know, we'd start with Rails and then back up to general, and this is a perfect example of this is that when you're in a Rails project, there's a certain directory structure that you can expect. And there's a certain way that the resources are, you know, that we expect them. There's a naming convention for how tables work in the database. And if you switch from Rails to Django, that changes, or if you switch from, like, on the team that I'm on, we're all writing in Python. And we don't use a framework. We wrote our own stuff. But it is very rigid.

There's a very solid process that we used for, you know, the way we get data from the database is standard. The way we transform it is standardized on our team. The way we load it into the warehouse is standard. And then, we write a custom piece for each of those three steps. But those three steps are very standardized at the interface or at the behavior level.

And coming from Rails into this team, instead of saying, "Well, I expect there to be an app directory or a models directory and a DB directory," I'm just saying, "Okay, what is the structure?" Oh, the structure is we're going to have this directory, and under this directory, we have these subfolders with these files in them.

And you, very quickly, you learn what is the layout of the forest? And that will tell you when you look at a tree, you're like, well, where is this tree? This tree is down in the model's directory, or this tree is deep in the ACL directory for this particular vendor. I'm like, ah, okay, I know where the holes are in this. There's going to be some holes in this file that are going to be filled in by the base classes because the app structure is going to take care of it for us.

TAD: So a follow-up question that I had is, it seems like both when dealing with legacy code and just any new codebase, your ability to just read code and have experience with code goes a long way. And I like your idea that there's tons of open source out there. But the thing is, like, they're not all masterpieces, right?

DAVID BRADY: No.

TAD: There's some really bad open-source code out there. So my follow-up question is, how do you find the masterpieces in the sea of GitHub repos?

DAVID BRADY: How does that old quote go? If you want to find a prince, you got to kiss a lot of frogs. I would actually say there's an essential code reading skill, which is the ability to, as you are reading through this piece, gets this, transforms this data, sends this message to this object. At the same time, you're doing that low-level, like, almost, like, compiling the code in your head to find out what it does.

There's also another thread in your brain that's basically assessing the quality of the code that you're reading. Like, is this code easy to follow? And is it easy to follow because it's very clearly written? Or is it easy to follow just because it happens to be in my preferred style? And I love the moments...like, I don't know if I would recognize a masterpiece if it smacked me in the face. But I do know that I become consciously aware of the feeling of pleasure reading code; that's how I'll phrase it.

I find myself smiling when I read code that I simultaneously realize I understand this code, and it's in a completely different style than what I'm used to, which means, in the worst possible way for this code to try to teach me, it's teaching me amazingly well. And that, I think, is...I don't know if it's a masterpiece, but it's certainly the code that makes me the happiest. I'm like; I want to write code like this person because they're communicating to a stranger very, very well what their thoughts are and how they want to accomplish the thing.

TAD: Excellent. We're at the end of our time. So I'm going to...I think we'll just end on that and just encourage all of our listeners to go out and read some code, huh?

DAVID BRADY: Right on.

This discussion explores software development, company culture, growth, and mentorship. Panelists talk about the importance of learning by doing, taking risks, and creating environments for safe experimentation. They emphasize the role of mentors and collaboration in personal and professional growth, highlighting their own experiences as well as the collaborative culture at Acima.

Kyle's reflection on his work with Python, Prometheus, and orchestration tools illustrates how good infrastructure enables diverse development, and others share experiences that stress the importance of small incremental changes, collaboration, and learning from hard lessons.

Transcript:

MIKE: Hello, and welcome to another episode of the Acima Development Podcast. Today, we're going to be talking about projects that really propelled our abilities to the next level, projects that moved us forward. There's things that you work on that don't really change your abilities much, and you can kind of fall into a rut, stay where you are for a while. Then there's those projects that really push your skills to the next level. That's what we're going to talk about. What's the difference between those? What are some of the projects we've worked on that have made a big difference for our skills, for knowledge, for our careers?

I'm going to start by sharing a couple of stories from my career. The first one I wanted to share is actually a really long time ago, like, 20 years ago. I learned from this project, not because it was a good one; I learned what not to do. I was working at a company that acquired a credit card processing gateway.

For those of you who aren't familiar credit card processing, you don't work generally directly with the networks. You go through an intermediate service that does the work of taking the credit card information and storing and talking to the credit card networks, and interacting with the bank, and putting the money into the bank. Then they call that a gateway. It does the work of interfacing with the credit card networks and the bank to connect the two together. They call it, it's like I say, a credit card processing gateway.

I've worked on a couple of those over the years, but we acquired one at this company I was working for. They had quite a few clients. They worked mostly with small businesses. They had a partnership with a company that worked a lot with small businesses, so they had a lot of business. But they were having some financial troubles. We took them over with the thought that we would help them grow.

Well, this service was written in VBScript. [laughs] It was a scripting language based on Visual Basic. It was used a long time ago. It was a predecessor to Microsoft's .NET that they have now, which is kind of a more solid platform. This old way of doing things was similar to some of the other scripting languages at the time where they just...they gave you a scripting language, and that's about it. So there weren't libraries for interacting, for doing clean interactions with the database. You kind of built everything yourself.

And the people who had implemented this had written a query where they didn't sanitize their inputs. They just took input straight from what people had submitted to the application and sent it directly to the database. For anybody who's not familiar with that, that's considered the number one security no-no, [chuckles] that it allows a malicious user to send in a little snippet of text that will allow them to interact with the database. And that's exactly what happened.

Shortly after we took it over, and perhaps even before we took it over, somebody had started exploiting this hole and ended up stealing, I think, over a million dollars from users of this gateway, which was terrible. And I had to go through and try to figure out what was going on in the code because we were told that there was a problem, like, there's something that seems funny. And so, I had to start going and looking through the code and trying to find where something, who knows what might be funny. I found this SQL injection vulnerability, like, oh no, and fixed it.

So, I learned dramatically when you choose to build everything yourself rather than using a library, you put yourself in a lot of risk. There's relationships poisoned between businesses with this experience, and it really kind of sent the company I was working at on a different trajectory that wasn't as good. It was a really, really bad thing because people had not taken the time to have a library that did things right.

So, I learned from that experience, and it sticks with me today. In fact, when I interview people for a job, I often ask them [laughs], still, what sort of security vulnerabilities they've found because it was such a poignant experience that it let me know how important it is to do things right when it comes to security.

Another story I wanted to share, I also worked at another company that was doing a content management system, mostly for publications like newspapers. We were doing decent business. But then we primarily focused on classified ads, built the content management system, and started bringing on newspapers, and we grew so fast. We grew...if I remember correctly, we had 10000% growth in a year in traffic. If you're growing 100 times bigger in a year, that kind of growth is very difficult to sustain because about every two weeks, something new would break. [laughs]

If you're doubling in traffic every couple of weeks, you quickly find things that were working and no longer are. In that kind of environment, I had to learn an awful lot about monitoring performance, addressing performance concerns, about tooling, about how to quickly address problems that arise. It was really invaluable the kinds of debugging skills I got and the kind of situational awareness of knowing what was happening and looking out for the kinds of things that might be going wrong next. We've got Kyle with us here who [inaudible 05:11] the DevOps team. So he's probably got some interesting insight on that.

Those are the two stories I kind of wanted to share to lead off our conversation. First, where I learned what not to do and one where I was really kind of thrown into the fire [laughs] and had to figure out what to do for an extended period of time, both of those were times when I learned an awful lot in a short amount of time. What stories do you all have or experiences you all have with projects that really pushed your career forward?

MATT: I have a couple as well, very similar to your stories. The first one would be I was a little bit earlier in my career working for a startup. And this startup, just for context, was the deal engine. They discount deals for various companies. And we started out a local deal engine here in Salt Lake City and ended up landing a national deal with one of the big movie theaters. And we were used to hosting probably 3,000 max concurrent users at a time. And our services were hosted in a data center single server. There was no virtualization, anything like that.

And it just so happens that they talked about us on Good Morning America. Almost immediately after, we got over a million concurrent users, and it just brought everything to its knees. And we had to act very, very fast to figure out some sort of a solution that wasn't going to put us out of business because, you know, servers crashed, and we couldn't have any site visitors.

So, what we ended up doing was just throwing up an email form of, hey, we'll get back to you as soon as we can get it back up, and then ended up switching to VMware. And long story short, I learned a lesson in scalability and how not to scale. We were nowhere close to being able to support that kind of traffic. And, you know, while that kind of traffic is great for a startup, it brought us to our knees. You know, eventually, the company, not a long time after that, went out of business, and I think it's because of some of those problems. So lesson is, don't scale too fast if you can't support it.

And I have one other story that's on the opposite end and more of a doing things the right way type of story, and that is a company I worked for in healthcare. Starting out, we had a system that was kind of similar to an ERP system. But it was custom-built in PHP. And we were doing a full system rebuild from the ground up and switching it to Ruby. And this is the beginning of my Ruby career.

And it was a really great experience for me and kind of pushed me to the next level because I learned a lot about gathering requirements, how having a really good product and project management team works, and how important it is to break tickets down into small incremental stories so they're workable and releases aren't going to cause a ton of bugs and testing. I had never worked in a test-driven development shop before, either. And just that experience it was incredible and kind of made me what I am today.

MIKE: [inaudible 08:54] I ask a couple of questions. That first place that went out of business, if your infrastructure had been built on a more solid foundation, and, you know, hindsight makes things easier. [laughs] You know, if you've been in an environment where everything was containerized, virtualized somehow, and was in the cloud, what difference would it have made to the company?

MATT: I think it probably would have saved them. They would have that national exposure, and it wouldn't have left a bad taste in customers' mouths. And, you know, I'm betting 90% of these customers that tried to visit and saw that everything had crashed didn't try and come back. And had we been able to support that, we probably would have got some return traffic and been much more successful.

And, to be fair, I was the IT director at the time for this company, and I probably shouldn't have been. I was still pretty early in my career and kind of fell into the position, and I didn't have the knowledge that I needed to be able to support the team as I should have. So I will take some responsibility because I shouldn't have been in the position I was in. And, you know, I took it because I thought, oh, wow, I get to be a director for this company. And I really shouldn't have been there. We should have hired someone with some more experience that was better suited for the role.

MIKE: We're talking about lessons, not about pointing fingers. You know --

MATT: Well, like, but it was a lesson to me that, hey, don't accept something you're not prepared for and you're not qualified for.

MIKE: So, it sounds like the other company they already had some people who were following best practices. It sounds like you were able to learn from people who had set up a culture and an environment of those best practices. Am I hearing that right?

MATT: Yeah, absolutely. And I wouldn't generally share names, but there's a company called Pivotal Labs, and some of you are probably familiar with them. EMC owns them, so now Dell. But they were one of the biggest contracting agencies in the world at the time. And they were very good in helping us learn and ensure those best practices. They came in, taught us test-driven development, taught us requirements gathering, and it was a great experience for me.

TAD: I'm curious, what separates the projects that will help a developer really level up and push their skill set versus a project that will crush somebody, and they'll be sad about it later on in their life?

MIKE: There's a Russian education theorist that came up with the idea of the Zone of Proximal Development that I actually love. Let me explain the idea. You draw a circle, and then you draw a bigger circle around that circle, and that's it. So, you got two concentric circles, a smaller circle and a bigger circle around it. Well, the smaller circle is what you can do alone. And the circle around it, the bigger circle, represents a larger area, and it's what you can do with help.

And the area between what you can do and what you can do with help is kind of ring-shaped. Picture these two circles, you know, a smaller circle inside the larger circle so that donut [laughs], that donut shape. That sweet goodness is the area between what you can do alone and what you can do with help. And that area is where you're stretched beyond your own skills, right? You're stretched beyond what you would be able to do normally, but with somebody who can guide you and help you accomplish things in that area.

And that area is, I think, where we tend to learn the most. If you're inside, you know, if you're in the what you can do alone, you can learn, but it tends to be kind of slow. And if you're outside of that outer circle, you're beyond what you can do with help. Well, then, you're just in an area where you just can't do it. And then you tend to fall flat on your face, and it's awful.

The sweet spot, you know, you don't want to be in the hole of the donut. You don't want to be outside the donut. You want to be inside the donut. That ring where it's harder than what you can do alone but something that you can do with help. In that area, you're really stretching. That's when you're going to make most use of the mentorship and training opportunities that you have. That's when...as Matt was talking about where he learned from others, he was learning new things that he wouldn't have learned necessarily alone.

There's more than one way to learn. You can learn from the internet, but a good mentor is invaluable. They really put you into that donut space. So, if I were to give an answer, I'd say that zone of proximal development, that sweet spot between what you can do alone and what you can't do at all, is, I think, where we do the most growth.

MATT: What a great analogy. I've never heard the donut reference, but that's perfectly stated. And it's true. If you sit in an area and aren't willing to take on things that you don't know yet and you may not be able to handle yourself, you kind of get stuck. And you get black-holed, and you don't really grow. But that was perfectly stated.

I think fear is one of those things that holds us back as well. We're scared because we think, what if we fail? And, you know, you have to be willing to fail and willing to accept help to grow.

TAD: Does that mean you're willing to push code even if that means bugs in production? That's the scary thing, right? It's what happens if I fail and the company loses a bunch of money or I lose data. Or, I mean, there's a lot of big things that can happen in our field due to mistakes or due to not having enough information or enough knowledge to handle something. That was one of your examples, right, Matt?

MATT: Right.

TAD: You're, like, we needed to scale, and we didn't know how, and we got crushed.

MATT: Yeah, absolutely. I think that's both sides of the coin. I think overconfidence can also have you push those bugs into production because you're so confident in yourself that you think everything's just going to work. That's why we write tests, right?

MIKE: Well, that's why we write tests, and you hit on some key things. There are things we can do to mitigate our humanity, right? [laughs] Our fallibility. We can automate. Like, with tests, we can automate the verification of what we're doing.

Further, we can collaborate with other developers. If you have two people look at it, you are less likely to have problems than if one does. Like, your risk goes significantly down. You never completely eliminate the risk. But you can, again, back in that sweet spot [laughs] between the center and the outside when you have somebody who can verify, who can give that second pair of eyes. It really helps to address some of those weaknesses we have when we're doing things alone, I think.

TAD: Interesting. Yeah, I think it's Etsy. Everyone has to push to production on their first day. And I think I read that they set it up so that anything that gets pushed can be easily rolled back. And it doesn't matter what you do. They have a mechanism to make it almost push-button rollback. So, the risk is very low.

And they just want people to come in and just get their hands dirty, get their feet wet, whatever you want to say, where it's like, yeah, look, you could just push to production, and you're done. That includes people that aren't necessarily even devs, right? It's, like, QA guys or whatever. If I remember correctly, they also come in and do something...it sounds like the idea is find that project, kick them out of the nest, but make sure there's a safety net so that it's not so bad and so scary.

MIKE: That infrastructure idea. Like you said, they make it safe to deploy. If you have a sophisticated deployment kind of pipeline, you can push out to, say, 1% or 5% of your users. And you kind of do the canary test there, you know, say, hey, is this going to work? Is there something wrong? [chuckles] And only expose a small percentage of the users to the risky new code because anything new is risky, as well as the testing and the peer review. And there's conversations about the code, you know, all the many things that we do to try to mitigate that risk, you know, add up to an immensely helpful system.

And I think that process of putting those things in place to make the deployment safer really changes our ability to experiment because if you can't experiment, you're not going to get very much done. And giving yourself that ability to bias toward action enables a lot of progress. So, a really good DevOps team can make all the difference.

MATT: Yeah, you have stated that very well. And as we're talking, I'm thinking, you know, these things we're talking about are the things that push us to the next level. And had we not gotten there and probably learned some of these hard lessons, we wouldn't know this. You know, small incremental changes. Make your PRs as small as possible. And you do create that safety net. And back in that first story I was talking about, I didn't know these things. And, as we grow, we learn these lessons, and they just make us better.

TAD: It's interesting because this is reminding me of a project that really helped me grow was I had an internship with Compaq Computers back when Compaq Computers existed. And my manager's manager came in to all the interns the first day, and he said, "Forget everything you learned in school." Not quite, but he said, "In school, you learn to do your own work, do things on your own, don't ask for help, figure it out, that kind of thing."

He says, "That's garbage. Forget all that. If you get stuck in the slightest, I want you to be talking to your fellow interns. I want you to be talking to the other engineers here on this floor because we have tons of expertise. And you're going to move much faster if you talk to somebody than trying to figure it out on your own. Because, yo, I know you're all interns, and you don't have a lot of expertise and stuff."

And it was kind of understood. But all of us were on the same floor in this building. And the hallway was actually kind of like a big circle. So whenever you got stumped or stuck, you would just kind of turn to your office buddy, who was another intern, and be like, "I don't know how to do this." And he'd be like, "Yeah, I don't know how to do this either." It's like, all right, time to walk the hall.

And you would just kind of think as you walked around the circle and did a few laps. And the other engineers, when they were free, would leave their doors open. And they'd see these interns, like, walking the hall, and they'd be like, "Hey, what's going on? [laughs] Like, why are you walking the hall?" You're like, "Ah, I got this thing."

And I remember I was trying to do something. I was trying to measure something and really calibrate something, but I couldn't get it working. And this guy is like, "Hey, what are you doing?" Then I'd tell him. "Oh yeah, the best thing to do is read this register in the processor, right? It says how many cycles have happened since the very first time it booted up. And that's going to be the most accurate way for you to calibrate what you're trying to do."

I'm like, "Okay." [vocalization] He's like, "Oh yeah, well, you have to use Assembly, right?" And it's "Oh yeah, I'll just email you the code I wrote." [laughs] So I was just like, "Oh, awesome. Like, thanks. I've been trying to figure out how to find enough calibration for the last three days, and you happen to have a snippet of code that does it for me, and you solved the problem."

But that was something where I had no idea. Every intern was given a project, and none of us knew anything about anything. And they gave us a whole summer, and I just [vocalization] [laughs]. But we went into the donut away from the hole, I guess, and learned a ton.

MIKE: That's great. Kyle, from the DevOps perspective, it's come up repeatedly how much difference good infrastructure can make that enables us to experiment more safely. I'm curious both what experiences you've had but also your thoughts about that importance of having good infrastructure to enable us to experiment with less risk.

KYLE: Yeah, I was sitting here thinking about those as we're talking about a few of these things. I would almost share...I'll start out by saying I'll share that there's probably been four things that I can think of that have really I feel like propelled me, I would say, and that's I got onto a QA monitoring team.

And one of my first projects that I had to take up was a dialer bot. And what this dialer bot did was it basically constantly called our beta environment and would make sure that the phone system was up. Anybody that's worked with phone systems, those are very particular. The average person, I would assume, gets frustrated when they try and make calls. Sometimes they just don't go through, and that was kind of the case that we would deal with.

And so, I had to design a bot that, you know, was resilient enough to determine, okay, well, this is just the phone system, or this is actually our code. This is something that we broke when we deployed. And that was interesting because I had to deep dive into Python. It was my first time really writing anything in Python of substance and getting that going. So that kind of got me into the world of monitoring. And that forced me into the world of, at the time, it was the TICK Stack, which is more so Influx, and its Telegraf to send metrics to a time series database so that you could visualize what was being monitored.

But the big one for me was the transition to Prometheus and how that ecosystem has grown. And I'll pause on the Prometheus side for now because...but it kind of goes back into the question that you asked. The one thing that really was a deep dive for me was orchestration tooling. My first exposure was Rancher, which was a great stepping stone, I'll say. It was early days for the Rancher guys and orchestration, and we definitely went through the growing pains with them.

We had, I don't know, we were probably up for two days one time when our Rancher orchestration went down at my previous company. But tell you what? When you're working on something with a group of guys for 48 hours, you tend to learn a lot about a system.

And then the next one, you know, is Kubernetes orchestration system, which has been amazing just to be able to see how that scales, taking systems like we had here where we were running directly on [inaudible 23:59] hosts and running services per host and being able to schedule six, seven services on a host. And then being able to manage that it's cut costs, and it's given us resiliency. And that's where I'd go back to Prometheus.

Prometheus gives us some of that time series database where we can have this monitoring and store all this information. So with utilizing a tool like Prometheus and then, like, Grafana to visualize and get alerts, we're able to determine quite quickly how fast our services are either down or there might be issues. But on top of that, you have these orchestration tools that have some type of a self-healing aspect to them.

And I won't throw any services under the bus, but there might be a service or two that they tip over every once in a while because, well, they've got some type of a memory leak. While on the Kubernetes environment, what happens there is it tips over. It gets restarted. You know, the service automatically gets restarted. Previously, you had to manage that yourself. You had to have something monitoring that that would see it. And either somebody would have to have a manual intervention or, you know, there would be something to say, "Oh no, restart this service," you know, kind of like Kubernetes does it.

And, on the other hand, too, Kubernetes has safeguards in there as well where, you know, if it starts using too much memory, it will get restarted. You know, it's a bandaid on the memory leak. The memory leak could be fixed, but it's a bandaid on it. That service continues to run, and it continues to operate. And it doesn't, you know, impact us or our customers.

There's just new techs in the infrastructure that have given us these bandaids or given us these luxuries that has allowed us to move faster. And I think, for this company specifically, it has allowed us to move faster in a way that we've been able to write a lot more services. It's been exponential the services that we've started with since I got here to where we are now and even the variety of services that we're able to deploy. We're not just a Ruby shop. We're a Ruby shop, a Kotlin shop, a Haskell shop, you know, it's something where good infrastructure, good orchestration allows you to be quite diverse in your ecosystem. Did that kind of hit on what you're asking? [laughs]

MIKE: I think so. I think of this idea you keep on talking about, having the good orchestration, having the infrastructure that enables things. I'm thinking about elementary schools that will set up a, you know, a playground [laughs] for the kids to go and play in that lets kids do things that are a little bit dangerous, right?

Like, kids fall off the swings, kids fall off the bars, probably break bones sometimes. My son lost a tooth once [laughs] or lost half his tooth. He broke a tooth in half by running into a bar. But they're safer than things that they might encounter as adults. You don't send them out onto a construction site, for example. As educators, as a society, we build these environments to allow the children to experiment safely in a way that there is some risk, but it's managed.

And then they get out of elementary school. They get into later on in school. They provide sports, right? Where you get to go and push the boundaries of your physical abilities in a not exactly a sandbox but a constrained space where the parameters are somewhat controlled to reduce risk. You know, the kids who play football they wear protective equipment or, you know, some protective equipment in other sports as well. This idea of providing an environment that allows experimentation seems to be a big part of what allows us to take those risks and learn some things.

Also, a recurring theme I keep hearing is that scale is going to happen, [laughs] that we're going to have to deal with that. And they can make you or break you. And you can learn a lot from it, but only if you've set up the infrastructure that you need to grow. And building a system that allows you to quickly scale up seems to be kind of vital. Interesting these recurring themes that we're hearing.

You know, we are talking about growth. But in order to have that growth, you need to have an environment in which you are allowed to grow without breaking too many things but also are forced to be in that donut, right? To be beyond where you would go if you're just left to your own devices.

TAD: As I was thinking back, this is maybe a bit of a random project. But something that kind of changed my trajectory was, back in high school, I was just kind of the goofy kid that kind of joined the computer science club to do games because that was the place where all the computers were networked together, and you could play games together and stuff like that.

And I had a teacher who took me aside, and she's like, "I think there's this thing that's really cool, and I want you to do, like, a research project on it and get back to me." And I'm like, "Yeah, okay, sure." And she had me learn about this new technology called Gopher, and nobody has heard of Gopher now. But it came on the scene about the same time as the World Wide Web. And she kind of challenged this other guy in the club to also do this thing.

And we were kind of against each other a little bit, right? Because he was like, oh yeah, this World Wide Web thing is really cool, and I think it's going to take off. And I'm like, [vocalization], whatever. This Gopher thing is really cool, and it's going to take off. And The World Wide Web won out there. But she'd feed us these kinds of projects to get us interested in things and learning about new stuff. And I'm a web developer today partly because my teacher back in high school kind of directed my interest into something.

MIKE: That's interesting. [laughs] On your own, you just played games. [laughs]

TAD: Yeah, right? There was a really fun Mac game called Bolo where there's this little tank running around, and you form teams. And that was most of the time in our computer science club. And she, honestly, I think she used the games as a hook to get people in, and then she'd redirect that into other stuff. She was very clever.

MIKE: I can say that when I've had good mentors, it's made such a difference. In my first year of full-time development, I'll say he's my boss; he was my manager, but he was my peer as well. We had gone to school together, and we were friends, remain friends to this day, stay in touch sometimes. But he was an excellent mentor.

We actually had some high school students working with us, writing some of our code. They had their own online game that they ran. I think it was written in PHP, and they had a decent community [laughs] out there playing their game. But then they also professionally, in their time when they weren't at school, were writing some code for us. [laughs]

And working with that environment where you had some very junior, very junior developers, and I didn't really have any professional experience at the time. I had a patient, and thoughtful, and knowledgeable mentor that was always sharing. And he spent a lot of time educating himself and was sharing those things. I think the expertise that he shared with me and his mentoring made a tremendous difference my first couple of years in my career and really kind of set the trajectory.

He was really interested in databases. He loved data. He loved interacting with databases and really focused on that. And to this day, it's something that I still love and identify with. I think partially because of that mentor that set me on that right direction, kind of like your high school teacher, Tad. Or, you know, Matt, you talked about the people who set you up with testing and other best practices. Having that kind of mentor who sets the stage can make it...well, it puts you in the donut, right?

MATT: Yeah, absolutely. That's one of the things I love about Acima is we really have a strong focus on mentorship. And it's extremely fulfilling to be able to help others level up as well. So I'm very thankful for that. And, Mike, you should get a lot of credit because you help push that, ensure it happens.

MIKE: Well, thank you. It's something I care about. I think it matters. Having that culture of mentorship and help is a key differentiator, not just to make your company successful, which I think it is central to. I think we've talked about it before on the podcast, but there's the research that Google did that found that psychological safety is the most important aspect on a team for success. And that comes down to what? Well, providing that mentorship and providing that kind of safe ground for people to experiment. So I think it's vital for a company.

But also, it's the kind of environment I'd want to work in. I want to work with people who help each other out and who care. [laughs] I want to be with a group of people who cares about each other. And you have to create that.

KYLE: I would point out too that—we're hitting on it—but just the ecosystem that you're working in that's a way of just leveling up alone. And I'll kind of second what Matt said about the culture here at Acima. I've worked at a few places where it is very much the QA department, very much the dev or the engineering department, very much the DevOps department.

There's not much intermingling, and I would say here those walls have been...they're really low. It's not like me and DevOps. It's not like I have an issue going and talking to any of the engineers. They're part of my team, you know, not direct team, but they're part of my team and very open to talk to, and that's not necessarily the culture at other companies.

Even QA I've seen hasn't gotten the respect that we do give them here at this company, you know, that they are part of engineering. They are very integral. We treat them the same as any of the other engineers. And with these mentorship programs, you know, it's kind of on you. We have these opportunities to go and learn. There's book clubs. There's the podcast. There's paired coding and stuff I know going on everywhere. I'm sure I'm not aware of everything that's happening but just the culture.

You know, we talk about orchestration and how that might, you know, elevate the company and help keep you rapidly progressing. I think a culture like one that Acima has, you know, and I'm sure other companies do as well, where that communication, the barriers are taken down, and communication is encouraged, you know, relationship building is encouraged. That's something that is going to elevate your career faster than sitting in a silo, you know, be it your own single silo or your team silo, right?

MIKE: Well put. And to kind of build on that and kind of connect that with what I was saying, you may find yourself in a company that's mediocre, maybe even not very good at having a good culture. You know, maybe there isn't an emphasis on testing or best practices, or, more importantly, on mentorship, on psychological safety, you know, on inclusion, and mentorship, and support.

There's a couple of ways you can deal with that. You know, if you're in a truly toxic environment, then maybe the best answer is to get out of it. [laughs] In a lot of cases, it's somewhere more in the middle where it's just sort of fallen into a slump. And being proactive, taking the initiative, and being the person to make a difference is what will push things forward.

To give an example, I was at a place a number of years back where they said, "Why don't we take some of our lunchtime," sometimes, we were already doing it, "and help out some people who are also at the company who want to grow their development skills?" And we started doing that. And there's one person in particular, a woman who was working at the front desk, you know, had a lot of ability. She had a lot of technical ability that was kind of being underused.

And she started meeting with us at lunchtime and pairing on tickets together, working on code. And we'd just take those lunch hours and help her. And there was somebody else, and I think sometimes two or three who were working with us to grow their skills. And that changed the culture of the company, right? Because now the developers were really interested in working with these people and invested in their success.

And people who were doing that investment have gone on to lead teams. And that woman who was working at the front desk is at another company leading an engineering department now [laughs] after having a successful development career, as part of her successful development career. It started small, but that seed grew into something phenomenal. And it just starts, I think, with taking that initiative.

If you haven't experienced that, and this is to the people listening, you know, if you find yourself in that position, step up and do something. You will make a difference. Go out and mentor somebody or start a book club. Do something to encourage that atmosphere of growth.

You know, Tad talked about walking around as interns and finding the people with the doors open. Find that environment where the doors are open and build on it. Open your door [chuckles], and let the interns in. Those things may seem small in the moment, but, in aggregate, they make a tremendous difference, not just to the individuals that you're helping, but to the overall culture and to the success of the company at a whole, and also to the health of even the industry.

I feel very strongly about this point. [laughs] I've seen it work, and I know it can make a real difference. Let's all try to help people get into that donut and have that sweet goodness of the zone of proximal development.

MATT: We can all play our part, right? We just need to take it upon ourselves to empower others and to empower ourselves. We can all make a big difference.

MIKE: Great. Thank you. Another great discussion. I look forward to talking with you all next time.

The conversation explores the complexities of modern web development, focusing on the evolution of front-end and back-end technologies. The group talks about the rise of front-end development, highlighting tools like Node and full-stack frameworks like Next.js, and covers the shift from traditional back-end frameworks like Rails to more versatile front-end-centric options like React.

Additionally, they emphasize the importance of understanding multiple languages, standardizing data-centric formats, and separating concerns. They also discuss the merits and challenges of different JavaScript frameworks, the role of Rails in quick prototyping, and Ruby's elegance as a language.

Transcript:

MIKE: Hello, and welcome to another episode of the Acima Development Podcast. Today we've got a few people here. We have Matt, Nathan, Ramses, and Bart. And we're here to talk about JavaScript a bit.

To give a little context, I've been doing web development for a while. I first started tinkering around with it back in the '90s. Back at that time, things were a little bit different. There was no such thing as front end, much of anything. The web was designed as kind of static documents that you would navigate between. So, in the early days, what you even think about as a web application, you had a website, and maybe you'd add a little bit of interactivity to your site. So you could do some things dynamically. But that was kind of a novel idea at the time.

So you'd go to a page, you'd request the page, and everything on the page would be built on the server, and they would send it from the server out to the browser. The browser would render it. And that was the paradigm. That was the paradigm for a long time. That's how it started. 1993, I believe, was the first web browser, although very few people were using it at the time.

And over the next, certainly the next 15 years after that, it was primarily done in kind of the same way. You'd make a request to a server. It would render that document. The document would be sent over the wire over to your browser. Your browser would then show it.

They came up with this language, JavaScript, that could run inside the browser, a little language. And at first, it was used for just doing tricky, little things like showing little decorations dancing around your mouse. [laughs] I remember that one back in the early days. And they mostly got rid of those because they were more of a distraction than actually helpful. People were just having fun.

But over time, people started to realize, well, maybe we could actually do some useful things with this language that gives us interactivity in the browser. And so they started doing things like allowing you to drag and drop, which was really useful compared to what happened before. And, you know, other sorts of interactivity where you get a little bit of animations, or maybe you click something, and you see something highlighted somewhere.

And that interactivity made the browser feel a little bit more like a desktop application. Well, over the last decade, that has really expanded. And we now have not just interactivity on websites but the whole idea of rendering has often been taken entirely away from the servers. The server is just a source of data, and the front end does all of the rendering. And that is a radical shift from the early days. And it was kind of hard-won because, you know, a lot of people would resist that because it breaks the paradigm. There are some changes there.

And Rails, the framework that I've done a lot of my career in, hasn't really moved along with that movement. They've kind of stayed; let's keep rendering on the server side. And they've come up with a whole kind of independent system for doing that, for sending real-time updates out to the client that are rendered on the server side so that the JavaScript can be kept minimal. It's kind of an opinion that they've expressed that is not shared by most of the web development community.

We're not in a goal here...[chuckles] not in the business of starting flame wars but rather talking about potential advantages and disadvantages of different approaches to technology.

I have with us here Nathan Pearson, who's spent a lot of his time working on the JavaScript front end, and he's doing so here at Acima. And so he's here to talk about the React way of doing things, you know, the JavaScript way of doing things and how that compares with kind of the traditional or the Rails way of doing things. So we can compare and contrast and kind of see the value that you might get from these approaches.

And that's kind of where I've started. I've started with my I've been doing this for a while talk [laughs] and shared a little history because it matters. And it kind of informs some of the debates people have because they have their history. So, Nathan, where would you kind of like to start with this?

NATHAN: Well, hey, thanks for having me, first of all. I guess maybe a good way to do this would be to describe if we're going to talk about a little bit of, like, compare and contrast with what Rails is doing versus what we see with other frameworks. Maybe we should talk about how Rails does it. And then I can get into a little bit more on the other side of things. But if you like, I can try to describe Hotwire to the best of my abilities. Although I'll admit, I'm not an expert in it, unless you'd like to do it if you've done a little bit of research on that or if you have some experience with it.

MIKE: I haven't used a lot of it but a little bit. And I think you kind of captured, like, even the name captures most of it. Hotwire is an acronym for HTML Over the Wire. So it's a framework that's designed to send markup, fully-built markup, like, fragments of the page over the wire out to the front end using WebSockets. So it's fast.

So there's some real-time communication with the rendering still happening on the server side so rather than the client side maintaining a full sense of the state of the document. That's really not handled on the client side. Rather, the server-side renders it, and the client side just kind of sticks the content where it goes, and that has its merit. You don't have to know JavaScript very much [laughs] if JavaScript is not a familiar language to you.

In a world where most people know JavaScript, maybe the advantage has diminished some. It keeps the paradigm that we've had for decades and doesn't force us to go into a JavaScript world. There are some advantages to that as well, including for accessibility. JavaScript sometimes isn't very good for accessibility.

NATHAN: Yeah, or for SEO, right? I mean, things rendered on the client. Yeah, I guess if I could, I'd maybe just add that...so as I understand Hotwire, you have kind of, like, the two...is there are two parts to it. They call it Turbo, which is kind of a mini framework that handles really a lot of sort of the unseen interactions on the Rail's side. And then you have the Stimulus, which allows you to kind of pepper in some JavaScript.

And I guess the big thing with Turbo is it's mostly built around Ajax, right? So it gives you this...I guess they call it unobtrusive interaction with JavaScript where you can sort of write most of your code still within Rails, kind of like as Ruby, using Ruby templates. And then you use certain directives to indicate that this is going to be an Ajax request, and really kind of just Rails handles it from there. You don't have to worry about how do you replace different components on the screen? That just kind of happens dynamically for you behind the scenes.

So I think that's one of the major advantages of it is that it sort of gets out of your way and lets you get your job done, like what you said, which is it gives you that more traditional way of thinking about working with the web as a document, instead of a dynamic application with a lot of moving parts. So it sort of simplifies that for you. But it gives you the benefit of being able to add dynamic sort of changes to your application without a page refresh. Would you agree? Is that a fair way of describing it?

MIKE: Yeah, I think it is. And, you know, for anybody who's not used Ajax, it's an old acronym for Asynchronous JavaScript...AJA...what is the name of the second A? It's [inaudible 07:07] for the JavaScript [inaudible 07:09] XMLHttpRequest. You can see why they...to shorten that XMLHttpRequest. [chuckles] I was around when they first started using that technique.

And Microsoft introduced this component in Internet Explorer back a couple of decades ago that allowed you to send XML, at the time, over the wire, and other browsers kind of cloned it. And it became the de facto way to send information between the browser and the server without having to do a full-page refresh. And it's only relatively recently that JavaScript has really kind of natively got that ability with the Fetch API.

MATT: Just those old days of building your own libraries for Ajax requests. It's sure come a long way since then.

MIKE: Yeah, it has.

NATHAN: Yeah. So I guess coming back to that just as far as laying the foundation for this talk, so, if we're looking at Hotwire, I would say that there's probably this scale, I guess, in my mind of on the one hand, you have more of, like, this classic way of working with web applications where you have a server-side rendered page that gets pushed out to a browser. And then, in the browser, you get JavaScript that gets sent as well. And then that then, you know, applies some interactivity on the page, so it's a little bit more dynamic.

On the other extreme of that, you have pure just JavaScript. So that page is rendered using JavaScript, whether it's in the client. It could, I guess, also be rendered server-side with JavaScript using Node. But JavaScript is really in the driver's seat of doing all of that.

And then I think from what I understand of Hotwire, you know, I haven't really worked with it, but it sort of falls in between those two. So it gives you some of the dynamic nature of JavaScript. But because it's still kind of wrapped within Rails as a full-stack application really focused on Ruby, it gives you the ability to sort of work with that and deliver a lot of that interactivity in kind of a classic way but with a lot of, you know, the modern features as well of making it really rich.

So it is an interesting proposition, but I'd say that's probably where it would fall in my mind is it's sort of in between these two extremes of how you may want to think about, you know, how web pages are delivered to a browser and where JavaScript kind of enters the scene.

MATT: Yeah, it may be worth noting as well that Turbo uses WebSockets, so event-driven.

NATHAN: Now, does Turbo always use WebSockets, or is that just the Turbo Streams part of it? Because as I understand it, Turbo is made up of three different pieces, you know, Turbolinks still plays a role, and it's just basic Ajax requests. But I'm not sure whether or not, I guess, I wasn't sure whether or not WebSockets are used universally with Turbo.

MIKE: I think it depends on kind of your usage. It's been evolving to this point. And I think you can rely primarily on WebSockets now. But you could still use kind of the classic Ajax-type techniques.

MATT: Yeah, you can go 100% the WebSocket route, but it is not required with Turbo.

NATHAN: Yeah, it's interesting. So, I'd say, coming back to this kind of other end of that extreme on the fully JavaScript side, I'd say probably React encapsulates that even more than any other purely JavaScript framework like Vue or Angular in that view. They kind of have their own built-in templating idea. They have what are called directives. So you will create some kind of HTML representation of what you, you know, eventually want to present out to the client.

And then you can add what they call directives on elements that are kind of baked in, or you can create custom directives that let you have certain interactions with those elements, whether it's managing their state, or replicating them, or looking into them in some way that allows JavaScript to control, you know, how those elements are managed on the screen.

React even goes further into JavaScript land where they use JSX, which is, like, a JavaScript representation of XML. Basically, it's just JavaScript will create all of your HTML. So it's not just your behavior, but it'll render your markup really similar to, I guess, what you would think of in terms of, like, I guess, ERB sort of does that. It actually does use HTML behind the scenes, but, like, the form builder and things like that that will create different HTML elements for you. React goes whole-hog with that. I mean, just everything is done with JavaScript. So there's some trade-offs there.

In terms of preference, I think I'd say some folks prefer having something like a Vue or an Angular, where you have these directives, this special kind of key attributes that are on these HTML elements. Some like the JSX approach. I do prefer personally the JSX approach just because it just feels like you have even more control. It's all JavaScript. And you can even do debugging statements directly in your markup, which you couldn't do, like, let's say, in Vue. So that's a really interesting sort of feature, and I'd say why I would probably categorize React on the most extreme end of, you know, really having JavaScript run your entire presentation.

MATT: Being able to debug in your markup is really powerful.

NATHAN: Yeah, it comes in handy when you're looping something. So you may want to check the state of your data as you're going through a loop. And it's a little hard to do that unless you can throw a debugger in there.

MIKE: There's also some strength in the idea that you never leave the language. You don't have two things [chuckles] where you have your language, and then you have your templating language. You just have your language. I think that is a real strength. You don't have the cognitive challenges of switching contexts.

NATHAN: Yeah, absolutely. And I think one of the issues with JavaScript that I struggle with, I mean, to date, is the toolchain. So, like, modern JavaScript doesn't look anything like what you end up delivering to your client, to the browser, when it gets, you know, pushed out into production. You have to transpile it down to sort of an older kind of more, I guess, like, acceptable sort of version where it's not...doesn't have all the modern bells and whistles.

The more, like, custom kind of templating, transpiling that you have to do things like with the Vue idea or with Angular where you have these directives and whatnot, there's just an additional layer of, you know, they call it pre-processing, getting it prepared for the web. So you just have to kind of stitch that into your toolchain and make sure that you configure that properly.

And it's just another, I guess, small point of failure if you're not, you know if you don't do that correctly. I mean, it's not a big deal. But it's just something to be aware of where everything is purely JavaScript. It just eliminates at least just that additional factor of having to juggle yet another plugin or a pre-processing library that you'd need to handle that stuff with.

MIKE: To take that a step further, most people don't write JavaScript anymore, right? They write TypeScript.

NATHAN: Yes, that's right. There's a new survey that came out for this year. Their claim is that in 2022, front-end developers, JavaScript developers, by and large, spent more time with TypeScript than they did with regular JavaScript, which is pretty impressive and understandable. I mean, if you've used TypeScript, you really can, you know, appreciate what type safety and, you know, the autocomplete sort of IntelliSense that you have while you're developing what that brings to the table. To be honest, after using it, it's kind of hard to go back to a language that doesn't have those features.

MATT: And it really helps you DRY up your code. And I was also just going to say something maybe to note is the configuration of these modern JavaScript libraries. You know, in the past, there wasn't really any configuration you had to do on your front end. But now you need to be aware of the configuration side of things as well.

NATHAN: Yeah, that ends up being kind of a big deal. And there are a lot of tools around that. The big one today is...they call it Vite, so it's spelled V-I-T-E. With React, at least, it used to be this tool called Create React App, which was built and maintained, and it's still out there. It just doesn't have that much usage anymore. But it was provided by Facebook, the same team that builds React. And it was just kind of like a one-button click starter pack for getting your React app up and running without having to worry about configuring tools like Webpack.

Vite sort of has the same thing. It's a little bit more flexible. It allows you to do this with Vue, or Angular, or React, or whatever framework you really want. It's not, you know, married to a specific framework like Create React App was. And it also allows you to modify your build process, this sort of pre-processing of JavaScript that you'd need, which is something you couldn't do with Create React App. That was always, like, a major complaint.

So, if you wanted multiple entry points, which, for example, if you're building a browser extension, you have multiple types of pages, you have a pop-up page. You have a background JavaScript page. You have what they call a content script. You'd need different entry points for those. And you couldn't really do that with Create React App. It just kind of assumed you just want a basic, you know, web page with React. So that was always, like, a big complaint, and Vite solves that. They allow you to be able to really kind of configure it the way that you want. It doesn't break any of the default configurations.

But you definitely need a tool like that these days if you're writing modern JavaScript, which is kind of a topic in and of itself. It's a radical departure from, let's say, things that I think we kind of grew up with, which is like, you know, the problems with the var keyword [chuckles] and stuff like that, and the various type of scoping problems that you'd see with JavaScript.

It's really changed quite a bit. They've introduced a module system, which gives you a proper namespacing system. You don't need to use those Immediately Invoked Function Expressions anymore to kind of contain your scope. So it's really come a long way as far as what, you know, the differences are.

MATT: You're actually the one that turned me on to Vite, and I have not looked back since making the change on any of my projects. So thank you for that.

And another great thing with some of these modern tools is live updates. That makes such a huge difference when you're making changes on the front end.

NATHAN: Oh yeah. It's huge. They call it the Hot Module Replacement where, you know, you make a change while you're developing. And you don't even have to refresh your screen; you just see it immediately. And, well, I'll tell you that that is such a pleasant development experience. It's really hard to appreciate that unless you do it, you know, and you see how elegant that is. It's just a...it's a really nice way to work.

MIKE: What I'm struck by as you're describing this, although it's not new, so front-end development is really becoming kind of like back-end development. [chuckles]

NATHAN: [laughs]

MIKE: There's this compilation process, right? You build a build, and you push it out. We started with front-end development being just little toys. And now it's really kind of the same deal as the back end was. And I think there are still a few folks out there who see front end as secondary, but it's kind of coming to its own, where it's the same basic processes we're doing for the backend.

NATHAN: Yeah, I mean, you can even go further with it and talk about Node, which is used for the back end. So there are full-stack frameworks like Next.js. I think there's also one called Remix that's sort of a similar type of deal where they're, I think, trying to creep into the Rails space. I mean, they're offering your full-on back-end layers of your stack, as well as the front end. But you don't ever leave the language. You're all in the same language, whether that's good or bad, I don't know.

I think as a developer, you always want to learn at least a few languages so that you can really kind of get a sense of what the differences are and understand kind of, you know, those trade-offs. But it is far more robust, I think than we certainly started with when we were talking about JavaScript.

MATT: Yeah, things like Next.js took a lot of cues from the Rails world, just the similarities, the dependency injection, things like that that are really great. And, you know, you said full stack. It makes it much easier to be full stack if you're using the same language across your stack instead of having to separate those language concerns. But full stack has definitely, I think, taken on a new meaning in the last, say, five years or so.

MIKE: You know, Rails was revolutionary in 2005, but that was getting to be quite a long time ago. The ideas that it spread out in the community have spread and have taken root elsewhere. So Rails really isn't the unique framework that it once was because just kind of best practices, the convention over configuration, or having a high-quality ORM have kind of spread everywhere. And I don't think that we should think that Rails is, wow, this is the only place you can get this anymore. Those ideas have gone elsewhere, and they've bounced around and sometimes improved.

MATT: Yeah, you can find them in almost every language now.

NATHAN: Yeah, so I use Node Express a lot of times for, like, a quick, you know, back end, if I have to put something together. It's less opinionated than Rails. I configure it so that it resembles Rails because just all of the patterns, MVC, for example. You know, whether you love it or hate it, there's something very familiar with understanding how to group your code up in the way that Rails does it. And I think it's just a quick way to get started.

A lot of the patterns that Rails introduced are so, you know, they're so, like, effective in terms of a mental model of how to work with a back-end system like that or a web system that they just carry over really well. And yeah, indeed, I see them a lot in a lot of different frameworks. I think Rails has been really kind of an inspiration for web development across the board.

MATT: I find myself doing the very same thing.

MIKE: So we've talked a little bit about...we kind of went on a direction there talking about the toolchain. But we haven't talked deeply about what are the compelling advantages of having, say, React that completely and, you know, and disadvantages. But tell me reasons to...advantages to having React manage everything so that no longer are you really running a browser web page but rather, you're running a web application using JavaScript that's managing everything that you see.

NATHAN: Yeah, I think it's a good topic, and it is helpful to juxtapose it with Rails. Not to bash on anything that Rails does, Rails does things in a different way. And it is possibly a matter of preference. But I think juxtaposing it with Rails...or there's Laravel and other frameworks similar to Rails that are still doing it in that way as well. So I think just thinking of whether you want to call that, like, the classic way, or kind of this sort of improved classic way of having a server-side rendered page with some unobtrusive dynamic JavaScript in there versus pure JavaScript.

What I would probably argue attracts me, at least for the React side of things, for the pure JavaScript way of doing things is, first, for me, I guess it's a matter of ergonomics, just the preference of working with React, or even if it was just pure Vanilla JavaScript, everything being in that world. So you have however you want to organize your code. You can co-locate it. You can think of it really kind of as its own independent unit. And you don't have to think about, you know, separating out these different parts that need to come together across the stack. You can kind of focus on it. So there are certain ergonomics that comes with that.

There's also the data sort of transfer part of it, you know, you're dealing with JSON data instead of HTML fragments. So that, to me, tends to...there's an attraction there. I guess it just tends to simplify it. And it tends to help me think about an application as being, well, I guess, the back end as being separated from the front end in terms of an API.

And when you kind of merge the two together into a single framework, that separation becomes pretty murky, and it's hard to sort of separate that out. So, you know, as your architecture grows and you have multiple services, and you may want to reach out across multiple services, you know, in my experience, it's just easier to work with JSON data or some sort of transactional data rather than actual fragments of a markup that you want to present in your code.

MATT: Yeah, I think that separation of concerns is huge. You know, it makes rebuilding a front end much simpler than if everything is tied together in a single, like, monolithic application.

I am curious to hear maybe some of the guys who haven't been doing it quite as long as us old folks in the room how they feel about the separation of concerns. Has it been harder for you guys to pick up on front-end development? What are your thoughts on that, if you have any?

RAMSES: Not any super strong opinions. I think it's just with any new language; you just need exposure to it and practice with it. I don't have a lot of practice with or a lot of experience with different JavaScript frameworks, a little bit with Stimulus and React now, and, I guess, Vite too; that's even less. [laughs] I think there's just so many different tools out there, so which one to go with is hard to say. Just find something that you like and learn it.

MATT: Yeah, sometimes picking is the hardest part.

MIKE: The specific thing that you were pointing out, I think, Nathan and Matt, you're both pointing out, which is that sending data in a consistent data-centric format between applications is better than sending document fragments that, you know, in a markup language is a better idea, I think that's a pretty compelling argument.

One of the reasons that the web was successful was that it separated presentation from the data. So a markup language like HTML...in some of the early days of the web, presentation started getting mixed in. You started getting tags that referred to style. And we had to kind of pull back from that where we don't have the tag anymore, for example, [laughs] if you remember that one.

Then we said, well, we're going to send you data. We're going to send you, you know, some markup, which is data that's notated, essentially. There's a description of the data, but it doesn't say how to present it. That's the browser's job. And so you just start with the data and let the browser figure that out. And if you want to determine presentation, well, you have a separate language for that. You have Cascading Style Sheets that describe what it looks like. And then, you have JavaScript that describes what the behavior is.

And by separating those concerns, we ended up getting away from the entanglements, and there's a lot better success in being able to conceive the problem. And even better than those document fragments, arguably, the markup still is a description of content.

But we could also send that in a different dedicated content language like JSON, where you have something that's more like just strings and integers, or Booleans. And if you're a lower level, then the browser can not only think about that as the document being in one format but maybe reformat that document and completely rethink it. And so it lets you go to a little bit deeper level and separate those concerns even more, which I think is a really great idea.

MATT: Yeah, and standardization is huge, right? Remember the days of building, like, SOAP APIs? And I have nightmares just thinking about that. But you can standardize things, and you expect something to come across as a different format. It really isolates it. And I think that is just a huge win.

MIKE: You don't write WSDLs for fun?

MATT: Yeah [vocalization]

MIKE: [laughs]

MATT: I [laughs] really do. I have nightmares of having to write SOAP API and WSDLs.

NATHAN: Yeah, that is definitely a huge deal. Like, especially when you're talking about your architecture growing and you want to think about, you know, having APIs. It's really difficult; I'd say, to do that. In a way, I'd almost argue that thinking in terms of a, you know, traditional view of what full stack means sort of limits you in terms of understanding how to really think about the API.

And, you know, if you really kind of just use the example of just building something like a class or a function even, if you think about that functions API, what kind of data is it going to take? What is its output going to be? At least I find myself when I'm faced with a problem that I need to solve; I think about it in those terms of, okay, I need to write this thing. And this is the way I want it to look. This is the way I want it to be consumed. This is the data that is going to come out of it.

And then the internal implementation, I mean, that just comes out as far as that's just the work of getting it to look like that, but the design really comes first. And when I think about, you know, systems and larger architectures, I think the same sort of thought process goes into modeling; what is your API? What data is it going to take? And what's the output going to be? And when you are really working with this full-stack approach, you tend not to find yourself in that mental model. You tend to think in terms of, okay, well, what's my UI going to look like? And, you know, so on and so forth. And I think that that has its place.

And, in some sense, this whole topic of data versus these fragments and whatnot they have their place as far as what you're trying to build. If it's an initial app, maybe even beyond a prototype, but you're out in the market, and you're kind of at a certain point in the lifecycle of your application that it makes a lot of sense to do it, you know, quickly, I think Rails serves that need really, really well.

But when you go beyond that, and you have multiple services, that model of having a purely full-stack framework that you're working with begins to get challenged a little bit. I'd probably throw that in as, like, one, you know, strong kind of distinction between these two paradigms of having this separation.

And I'd say the other part of this that kind of dovetails into it is, really, it's kind of a question of control. So Hotwire, what's really nice about it is that you don't really have to know very much JavaScript to really gain a lot of the advantages that JavaScript offers, modern JavaScript, right? Where you're able to refresh major chunks of the page or even smaller parts of the page dynamically without a page refresh.

But the issue that I have...and maybe this is a personal thing because I always tend to worry that, you know, what happens when I need more control? Especially if you're a newer developer and you're just starting out, and you're learning the Rails way of doing things, are you really going to understand how to debug a JavaScript issue that's baked into, you know, that Turbo framework? So that's the thing that I tend to be a little bit concerned about, leaning too much on that. Kind of it's such a nice abstraction, but it removes you so much from the bare metal of JavaScript that I would say you could run into certain issues while you're developing.

I'm also not sure whether or not...and I don't know if this is totally related to that point. But there's this concern, I guess, I have of whether or not it can handle all the use cases that I've seen, so like routing, for example, would be a big question for me. Like I said, I haven't used Hotwire, so I don't have the experience with it. But in the current app I'm building, there's, like, a stepper interface where you go through, like, a wizard from one step to another.

And those tend to be done...I've seen them done in multiple ways, one where the URL doesn't change. So the browser's history doesn't play a role. There's no routing at all. It's just the UI is purely changing. And then there are other cases where you may want that, whether it's for SEO reasons or whatever, you know, reasons you may want someone to be able to click into a specific, you know, pass a link somewhere and be able to click into a specific step, same thing with, like, an accordion interface.

I don't know how well a Hotwire would manage or allow you as a developer to manage, you know, that history and that URL change in between a UI like that. Maybe it would. And when I think about it, it seems like a pretty complicated case.

MIKE: I was talking to a friend the other day about another case that I think is also challenging for a framework just trying to avoid JavaScript, which is optimistic writes. That is, suppose you're looking at a list of things, and you...[inaudible 32:10] is looking at a list of things, and they want to delete one of them, say it's a task list. And they click to delete one.

If you have full control over the front end, you could delete that element from the page and then run the actual deletion in the background asynchronously. Think about it that way. And I think you could do that in something like Hotwire, but it's going to be challenging. But if you have a model of the document already, it's much easier to think about that kind of situation. And that, you know, you remove it from the page, and then the user gets instant results. And then if something goes wrong, well, then they get a notification, and maybe it comes back.

But the idea of being able to think about your document in that way, rather than having to be kind of chained to the back end at every step. That you can think about, you know, what if you want somebody to work offline? Why not just build a whole pool of updates that they will make once they get connected? And that is so far removed from requiring all of the rendering to be done on the server side. You know, I think it becomes utterly impractical.

One kind of unstated requirement of having something like Hotwire is that you're always connected because you rely on the server to do everything, which means that you're tightly coupled. And that coupling has some problems associated with it. Now, it may be hard to do things without being online, but I think there are some applications that it makes sense to be able to keep the user largely functioning without having to be always connected.

NATHAN: Yeah, absolutely. And that, to me, also dovetails into this whole issue of mobile. I know that Rails team is working on something right now for Hotwire where that will provide an answer to the mobile question, but I haven't seen that yet. In fact, I haven't really seen it with many frameworks. So there really isn't a mobile answer on the Vue side of things or Angular. React, however, does have that. And I'm sure that these other frameworks can follow a similar sort of model for it.

And that's one of the things that's also really attractive for me with React is that you may not be able to reuse all of your code, but you can reuse a good chunk of your code if you're building an application that needs to be delivered on different platforms. Mobile isn't the only thing. You can do desktop as well. So, you know, Slack, for example, is a JavaScript app run on Electron. So that can all be done with React.

And so you can imagine being able to...if you're a smaller kind of startup and you have a smaller team, you can build a lot of functionality that can be reused, you know, APIs, various services, and whatnot that you need to process data validations, various schemas. A lot of the plumbing that you would need and across all of these different platforms can be reused with some pretty minor changes on the, you know, the UI part of it.

So, you know, with mobile, you have a different UI concept. It would still be in React. You would just be using different sort of gesture and animation kind of libraries than you would from, like, a web UI. But even that, if you build your web UI, you can glean kind of how you've separated out your components and organized things and apply the same sort of hierarchy of structure of how state is managed and whatnot in the UI, even though it's using a slightly different framework. So you get a ton of that reuse.

I'd love to see how Rails answers that. Like I said, I know that they're working on something. I am curious how they're going to do it. But that is one thing that's currently lacking. And so, in some way, if you're talking about full-stack Rails, you miss a little bit of that control on the JavaScript end, and it really doesn't at least today, it doesn't have, you know, an answer to the mobile question.

MIKE: We've talked a lot about the advantages of the JavaScript front end. The other question, when might you want to go with something like Hotwire? I think you've just touched on something important, Nathan. You talked about, you know, you're a startup. You don't want to hire a bunch of people. And so you might want to keep your staff small. And sticking with one framework helps you do that. Does Rails provide that advantage in some circumstances? So, who would you recommend Rails to?

NATHAN: Yeah, I mean, absolutely. Like, you know, in our case, at Acima, when we first got started, I think Rails was the perfect fit. It still is in many situations where let's say; the UI doesn't change very frequently. It's pretty stable. And it doesn't have a ton of interactivity or demand from consumers. Maybe LMS would fall into that category. But the idea is, yeah, it can certainly, you know, serve a really meaningful sort of role within that kind of a context.

A startup with a small team of people that know the framework really well, who aren't really interested in, you know, some of these broader issues or these tangential issues that come up as you mature. They're just interested in getting the meat and potatoes up and running. And, oftentimes, even can live with those because that's good enough for the application. I think that Rails is probably, and still, I think, the leading framework to be able to do that.

MIKE: I think it gets you up and running quickly. If you only want to have people learn one thing, and that thing is pretty easy to learn, Rails is a great choice there. You mentioned LMS. For those listeners who probably don't know what that is, it's just an internal tool and things like that where you're not going to have a lot of updates to the UI. It makes sense. You probably want to keep it simple.

MATT: You can just get to market so quickly with a Rails application. It's always been my go-to if I want to quickly prototype something or just get something out because it's time-critical. It's powerful, and it's fast.

NATHAN: And there's also the language preference issue, right? I mean, Ruby is such an elegant, beautiful language. It's not just easy to learn. It's really just easy to work with. It does so many things in such a right way that it's just really just pleasant from a developer experience.

There are things in which, you know, I wish that they can add in a way that makes sense. I think they're trying to add some type safety to it. I haven't really played with any of that. And from what I've looked at in blogs and whatever, I don't know if I just intuitively got it right away by looking at it. But it'd be nice if that was something that found its way properly in the language and, in the framework, a bit of a different topic. But outside of that, I mean, you know, Ruby is just a fantastic language. So I think if you have a preference for that, Rails is just such a natural, elegant complement to it.

MIKE: Yeah, so I'm with you. If you want to get something up quickly, Rails is still, I think, a very compelling option. As you grow, it might be worth considering rethinking the front end. I'm speaking to Rails developers out there. [laughs] Rails does some great things, but it's not the only way. In fact, it's become kind of a niche, idiosyncratic way of doing things on the front end.

And because React has just been very useful, you know, it's a useful option that has largely taken over front end because it works. There's always somewhat of the hype train where people do it because other people are doing it. But there have been a lot of options for front end for a long time. People have not been locked down into one option versus the other. And they've stuck with React because it works. That model of thinking about the front end as being as serious of a thing as your back end has some real merit in a lot of circumstances, I think.

NATHAN: Agreed.

MIKE: I think we've covered some really central points. [chuckles] When you're thinking about the front end, the value of using a framework like React for front-end rendering and the decoupling that it gives you, the advantages of thinking API first.

We've also talked a little bit about how it breaks the traditional web paradigm. In some ways, that's still broken. Things like SEO and accessibility still haven't been entirely solved yet because the web was not designed that way. There's still some growth that needs to happen for us to get there. And if you want to get quick to market, maybe that's still not the best way to go. So there are advantages and disadvantages to everything. Now there's another tool to maybe consider putting in your belt [laughs] so that you can use it for the next problem you address.

And thank you, and we'll talk to you. You'll hear from us anyway next time.

Today, we talk about challenges that we went through on our path to building a software career.

Transcript:

MIKE: Hello. Welcome to another episode of the Acima Development Podcast. I'm Mike. I've got with me Eddy, Tad, and Kyle. And today, we're going to be talking about challenges that we went through on our path to a software career. Those of you listening will be able to find both hope as you're going through the tough times but also find things in common, like, oh yeah, I relate to that. It's not just me.

I've been thinking about where I'd like to start our episode today, and I think that I'm going to start in 2002. If anybody was doing their career at the time, in 2001, there was the horrific attacks on the skyscrapers in New York on September 11th. And it was, you know, a great tragedy for everybody involved with that. And another consequence of that is that it precipitated the demise of the bubble in investment that had taken place in tech at the time.

During the late '90s, there had been a bunch of investment in this new internet thing. [laughs] And people were trying all kinds of business ideas on the internet to see if they'd work. Some of those, famously, were ideas...they lost money on every transaction, but they made up for it in volume. [laughs] A lot of those business models...famously, I think pets.com at the time was just losing loads of money. Investment kept them running. But once the investment dried up when people got scared, the whole tech economy just tanked, and there was a bunch of layoffs.

It was kind of the seed of a lot of new stuff in tech as people said, "Oh, wow, I can't work for that company. Well, maybe I'll go try something new." And it worked out in the long run. But it was not a great time to be looking for work. And I had been doing some tech work at the time. And I was finishing up school and went out to get a full-time job, and there was just nothing. [laughs] And I was in a bad spot.

I remember just every day feeling like I am so useless [laughs] because I was unable to find anything. I put out lots of resumes. Nothing ever came back. The people I interviewed, with I didn't always hear back from. So I spent several months working part-time doing some kind of freelance work while looking for a good full-time job at the time.

Eventually, I got a full-time job. It didn't pay very well. But I stayed there for a while and built it up over time and have been full-time in development ever since. And I think those three months humbled me [laughs] and taught me a lot about keeping on going, even when it looks like there's not a whole lot of options in front of you.

And that's kind of where I wanted to start is there's one anecdote from my career from a dark time, dark time for the world really being scared at that moment but also difficult for somebody seeking a career in tech that, you know, it may look bad at the moment, but things do look up. What experiences have you all had?

KYLE: My experience was a little bit interesting because I came from a small town where if you had any interest in computers at all, you did everything with computers. And my only knowledge of the field was, okay, well, I'm going to go to school. And the first thing that I saw, you know, was computer engineering. I was very interested in hardware at the time, so it was a perfect fit. I'm still interested in hardware. But that's what I ended up focusing on was computer engineering.

I didn't know about any of the fields that were available. I was actually in a calculus class. And one of the guys there that I had been becoming friends with, you know, he's just basically like, "Hey, do you need a job? Come interview at my company." You know, he's telling me about this QA testing and IT, you know. I had an idea of what IT was, but I had no idea what a QA tester was and what that even did in software.

So I went and interviewed and landed the job, luckily, and got into the field. And that was one of those things where it was kind of exposure. You know, all of a sudden, I'm learning there's software engineers. There's IT; there's DevOps, there's implementation specialists. Just all of these different branches of software that I'd never even heard of didn't know what they did. I thought a computer guy just did computer stuff. [laughs] And it was very humbling in that sense. So that was something foreign to me at the time.

And I ended up going through my career in the sense that, you know, I started out in manual testing. I went to QA automation, went to load testing, and found myself on a DevOps team when none of those paths were what I was originally thinking that I would even do.

MIKE: And it's interesting. You weren't even aware that they existed, right? [laughs]

KYLE: It's one of those things, like, even to this day, it's, like, if you're not in tech, you know, people ask me, "What do you do?" "I'm a DevOps engineer." "A what?" "I work in software." You know, it's something that people just they have no idea about this. You know, even if you're interested in it, like, and then explaining outside of the industry, like, what it is that you do, I mean, DevOps engineer, systems engineer, right? At least people will go, "Oh, okay. I know what a programmer is." And, from a high level, what I've found is [inaudible 05:12] that's about the best you get.

MIKE: And, interestingly, DevOps, in particular, is a relatively young field, right? Much younger than software because it used to be you just had system administrators [laughs] and figuring out how to make that work and treat it as a development-type thing where you have configuration management. And I've heard it well-put; you treat servers like cattle rather than pets, [chuckles] where they're just a herd of things. You don't treat them individually, but, you know, you manage them as a group. That's a different take that's really only been a meaningful field, and for about what? Ten years, Kyle?

KYLE: Yeah, and it's even expanding, right? Because even those of us that have been doing DevOps now for a few years, it's, oh, I was in systems engineering. Well, I kind of do more DevOps-y stuff now, right? And then now there are several other, you know, buzz titles is what I'll refer to them as. You know, you've got SREs, Site Reliability Engineers. That tends to fall under the DevOps category. You've got cloud engineers. You've got...what's the name? Platform engineers, right?

And it's trying to navigate and figure out, like, with my DevOps skills, do I land under those? Am I more geared towards that? And I think what you're getting at is, you know, we started out managing, like, on-premise servers and setting up workflows there. And that has evolved into a world where it's all in, like, on the cloud, and you're managing on-demand hosts, and, you know, you are treating those as pets, right? Each of those had a name, and you cared about them.

And now we're entering into a world where hosts are disposable. If you're not using it at the time, why keep it around? You don't want hosts that are sitting there doing nothing. So, yeah, they're like cattle. If they're not doing anything, if they don't have anything running on them, just go ahead and kill them. Get rid of them. You don't use them, you know. And we have orchestration tools, which is a new tech, which manages that and tells us how many cattle we need at a time. It's a very rapidly changing field of software.

MIKE: Yeah. And you were going exactly kind of where I was thinking is it evolves and changes, and some of the subfields there didn't exist even a few years ago. Web development, as a field, didn't exist when I graduated from high school because there was no web. [laughs] It wasn't an option because that field didn't exist. Likewise, with DevOps, there's something to be said there for that need for continuous growth and recognizing that it's okay if we don't know about the field because maybe [chuckles] it didn't exist a couple of years ago.

KYLE: Even in software, it's the same way, right? I mean, it used to be that, oh, I'm a programmer, you know. And, like you're saying, well, now there's web programmers. Well, to expand on that, you're not just a programmer anymore a lot of the time. I hear the term software engineer used as more of that blanket statement anymore. But if you're a programmer, you're a Ruby dev. You're a Python dev. You're a front end. You're JavaScript. You're Node, you know. There's 100 different languages now, and people are specializing in those.

And to even get deeper into that, you're specializing in what libraries in Java for the web development, right? Like, on the front end, you've got all these different front-end libraries to manage the front end. And it's you have specializations there just because those libraries are so huge anymore.

MIKE: Absolutely. You learn a framework, and you define your career. And we can talk a lot about web development, but then there's machine learning, or, you know, systems coding, or desktop development, game development, all so specialized that we don't tend to crossover between them very much.

KYLE: Yeah, that's true. I mean, speaking of things that are new, if you did system programming for the longest time if you didn't do it in C, you basically weren't doing it. It's been within the, like, what? Last year or two? All of a sudden, Rust has come on the scene, and they're starting to do that low-level stuff in Rust.

MIKE: Yeah, Rust has just really exploded. [laughs] It didn't even exist a few years ago. Oh, we've talked a bit there about that need to recognize that new things are popping up.

Tad, I'm interested in what thoughts you have about the challenges you've gone through in your career.

TAD: It's interesting. When you first posed that question, I kind of stopped and thought for a bit. And I think I've got maybe two stories that probably contrast and are interesting.

I was actually thinking back to the first time I ever contributed anything to open source, and this was back when GitHub was pretty new. And everyone was talking about open source and how important it is for you to get out and contribute and things like that. And I was a fairly new developer. And I don't know that I was terribly confident in my skills probably at the time.

And so I found this project, and I'm like, okay. I think it was called, like, a Cookbook or something like that. And people were contributing a bunch of code samples to it. And I noticed that none of the code was syntax-highlighted, really. And there was this really popular theme going around at the time. I can't remember even what the name of it was.

And so I'm like, okay, I can figure this out. I will clone the repo. I will format all the code samples with this new theme. I'll figure out how to do the CSS for this theme that everyone seems to be liking, and I will push it back up as a PR. And that will be my first kind of dip my toe in experience to software development and the wider world of open source and things like that. And I submitted it.

And the first comment was, "This makes my eyes bleed. I hate this. I can't believe someone would think this was good," [chuckles] right? And I remember just reading that. And after someone says something like that, you know, there's sometimes pile on and like, yeah, this is terrible dadada. I'm like, oh, oh gosh. Uh, oops. [laughs]

You know, it's one of those things where you're like, I thought I did something awesome. And I thought I was sharing, and I thought I was doing great. And to just have someone else come along and just kind of, like, pound you down is just...it's a little rough. And, unfortunately, in our domain, there's a lot of, like, you can kind of accidentally run into some of that harshness.

Like, some of the first questions I ever asked on Stack Overflow, same thing. You know, like, "Oh, this is a stupid question." "Oh" [vocalization]. You know, like, oh, [vocalization]. All right. Okay. You know, you kind of, like, tail between your legs. And you're like, okay, I guess I won't contribute to that platform anymore.

And I think that has been an interesting challenge that I've seen sometimes with younger developers is that they need to kind of be nurtured and sometimes protected from that kind of thing. Because I remember joining my first Linux group, and it was just email threads, like, yo, RTFM, RTFM. Like, anyone would ask a question, and they're just like, yeah, read the manuals kind of thing. And so that's been interesting to see. Hopefully, it's been changing. And, hopefully, we do a better job of kind of nurturing young talent.

But, Mike, I think when you were talking about that, I graduated the same time as you roughly. I think a little bit later than that. I came into a world post-bubble. I'm like; I can't even find a job. I might not have the skills. So I actually went back to school and got more skills and then joined and had a little bit more success. But, anyway, that's kind of some of the challenges that I saw when I first started out.

As a contrasting story, I think I'd like to sing the praises of a guy. Unfortunately, he's passed away now, but he used to be really big in the Ruby community, named Jim Weirich. And I remember one of my first projects; my company just decided this Ruby on Rails thing looks interesting. Maybe we should try it. And I was learning Ruby and trying to figure things out. And I needed to do XML for something. I don't even remember what it was.

And I found this gem called...I think it was XML Builder. And I'm like, oh, this gem doesn't work for what I need. And so I thought, well, I'll email the author and see if he can include this feature in his gem, and then it would work for me, right? And I just kind of naively sent him an email. He actually pointed out to me, he's like, "Oh, actually, my gem does exactly what you need it to do, and this is how you would do it. Your approach would work okay, but here's a different approach." And he sent me some code samples and kind of guided me along. And I was like, oh, wow, this is really good. This is good stuff.

And I didn't know who he was. [laughs] It turns out, like, those of you who are kind of in the Ruby community, he's the guy that wrote Rake, and he was really involved early on. And he did some of the bigger gems, like, early on in Ruby's history. And that has really stood out to me that he could have easily told me, "Oh, that's in the documentation. Go figure it out." And it turns out it was. I just had overlooked it. And I didn't have enough Ruby experience to have understood that what I was looking for was there. I needed to experiment a little more and figure it out.

But it was really interesting to see. He's like; I'm just some rando on the internet sending him an email. And he took the time to very carefully and very thoughtfully answer my questions, point me in the right direction, and make me feel better about what I was working on. And I think I'm lucky that I've had those experiences as well, or else I might have just dropped out of computer science and programming and things like that. Because I'm like, I don't know, this is a hostile place. This is not fun to do.

MIKE: It's interesting. I started by talking about kind of environmental difficulties, like, oh, we were going through a bad economic climate. And Kyle talked about difficulties of just knowing what was out there. You're talking about the human difficulties, and sometimes those are the hardest, right?

TAD: Yeah.

MIKE: Dealing with people who are unkind can be really crushing. But you found people who saw your worth. It made a big difference.

There's probably somebody listening who's feeling like, yeah, there's somebody who acts like a jerk to me, [chuckles] you know, because it happens. It's one of those things that happens in life. I think it's important to realize that sometimes people will act like that. And you should probably remember that it's more about them than it is about you.

You know, even the theme that you'd put out there, CSS can be changed. Colors can be changed. [laughs] And the idea of adding a style is a great one. And somebody who has a difference of opinion as to what the colors should be, we call that bikeshedding, where you argue about what color the shed should be painted. And it's really not the important decision. What's important is, like, how do you build the nuclear power plant? There are some very serious decisions that go into there, and what color the bike shed is painted doesn't really matter.

The fact that there is a nice shed that you can park your bikes in is the important part. But sometimes, you need to recognize that there are people out there who are not as capable socially as others. You know, some people may even be suffering from some challenges there. They have difficulty responding in social situations. In general, you should not take it too personally. Again, that's hard, but you got through, Tad.

TAD: Yeah, that's the thing is, like, I've made some really major contributions since then to open source. Like, I'm just hoping that talking about challenges for people listening to our podcast, I'm just hoping to give people some hope. And say, like, I think everyone starts out new, and inexperienced, and rough. And I think a lot of people have wondered, do I keep doing this? [laughs] And then you find something that kind of keeps you going, and turns out you can do it. And it turns out you can get better. And it turns out there are resources out there. You can find a mentor, or you can find other people that will be your cheerleaders instead of your detractors.

KYLE: And just to point out, you know, that I've had similar experiences. When I was starting out, I got ripped because I didn't know how to use Git. And I had a developer that just...he tore into me. And I ended up feeling pretty bad about that and going back to another one of the engineers and just like, "Should I know how to do this?" And they were level-headed about it. And it's just like, "You're new, right?" And it's like, "Yeah." "Did you learn this in your classes yet?" And it's like, "No," you know.

But I've come to realize that it is the bad days, or it is those people that have a challenge communicating. There's going to be people that are bristly everywhere. But it's one of those things where, okay, if they're going to be bristly, go to somebody else; ask them for help. And then you expand into the internet, right? And nobody knows who you are. They don't care who you are, for the most part.

I've had that experience where it's one in five, one in eight, or whatever the ratio is of what I'll post on, like, Stack Overflow questions there, on if I'll get a bristly response or, you know, and people do pile drive. If one guy is just like, "You're an idiot. This is a stupid question," they'll jump on it, and you get downvoted into the floor. But most of the time, people are willing to help.

And I always go back to the situation where maybe it is a stupid question. But nobody knows it's a stupid question until it's a stupid question. And I'm sorry, but I search for those stupid questions all the time on the internet. I want to know answers to those stupid questions. So, if you've got stupid questions for the love, please ask the stupid questions so that I can find them and get through my tasks as well.

TAD: Right. I think there's nothing more disheartening than I've got a question; I search on it. And I get a Stack Overflow response, and the person has the exact same question as me, but there aren't any answers. It's just critique. And you're like, oh, dang it. [laughs] Like, ah, you had the exact same...I wish someone would have answered it, and both of us could have gotten something good. It's just frustrating to see that people aren't getting helped. And you who needs the same answer also didn't get help eight years later or something.

KYLE: It almost feels like a lot of those responses; they took more time to tell you that you're an idiot than it would have just been to say, "Oh, well, it's easy, this one-liner."

TAD: Right.

MIKE: You know, in more in-person situations, in meetings...but it applies kind of universally to ask the stupid questions. [laughs] If I'm feeling a little bit lost about something, I try to put myself out there and ask the dumb question first. Because I've learned that, in most cases, there's several other people who had the same question as I did and are trying to figure it out, and they really appreciate somebody giving an answer to that. So, if I can expend a little bit of social capital to [laughs] get my question answered, it's generally well-appreciated.

And, in the end, there usually isn't that much social capital expended asking those questions that may seem personally dumb. Yes, there are people who will treat you bad. But, in general, you ask those questions, and people will be like, oh, did I miss that? And they'll go back and revisit their assumptions.

Communication is hard sometimes because you don't necessarily have shared understanding or assumptions to begin with. And the person talking about it may have more comprehensive knowledge and leaves out important pieces of the story. And, if you don't ask those questions, you miss those pieces. And it wasn't deliberate on the person who was talking about it. They just didn't know that the people in the audience had that gap. It makes sense to ask the question.

KYLE: I would even say, too, those of us, you know, maturing in our positions going into more of the senior level role, right? I feel like a lot of my growth, at least, is learning what it is that I'm not communicating and responding to the quote, unquote, "stupid questions" and going, oh, how did I not explain that? Why is this person not understanding me? So I feel like there's growth on both sides that can be had from these types of situations.

MIKE: Absolutely. Like I said, communication is hard. And I know that I'm going to leave some things out, not deliberately but just because I'm fallible.

We've talked some about the environmental issues that come up that make things hard and just keeping on working through them. You know, economic downturns happen. There's been a lot of layoffs. We're recording this in 2023, and there have been a lot of tech layoffs over the last few months. And that can be really rough if you're one of the people laid off. That doesn't mean that there aren't jobs out there, that there won't be jobs out there forever. There are cycles in the industry, and it's always come back up. It's not permanent.

TAD: From what I've seen, there are still tons of tech jobs out there. It's just some of the bigger companies maybe overhired and needed to make some correction. Because, from what I've seen, there's still plenty of stuff out there. I mean, software is still everywhere, in every industry, in everything. I'm not too worried.

MIKE: No, me neither. And I've seen unemployment rates in software, and they're not high. [laughs] People are just leaving some of those big tech companies and going to smaller ones. You know, those kinds of environmental challenges that you might have to deal with, but you work through it; you'll get through it. [chuckles]

And then there's, you know, the knowledge gaps that you might have to work through. Again, we all have them. Because the industry moves forward, it's inevitable. It's built into the structure of the system that you're going to have knowledge gaps. And by continuing to embrace learning, you can fill those and, you know, and thrive within your niche that you find yourself in.

And, finally, there's, you know, those human issues we've talked about that are maybe most challenging and recognizing that it doesn't say everything about you. And it may say nothing about you when people are unkind. It may say more about the speaker than it does about you.

TAD: A lot of times, we talk about learning new things. Some people see that as an opportunity. Some people see that almost like a death march. Like, I can never stop. I can never rest. I have to keep learning all the time, and I'm constantly paranoid that my skills will become obsolete. Because we're talking about challenges kind of in our field, how do you navigate that? Meaning, how do you navigate the constant learning without it being a death march?

MIKE: That's a great question. As you said that, I want to reply to that by talking about my two-year-old. He gets up in the morning, and as soon as he's finished yawning, he'll get down, and he will start running and finding the nearest thing that he can touch, and manipulate, throw, step on, jump off of, dismantle, put together, and do something to try to influence it and see what happens.

He'll do an experiment, like, how does this work? And try to figure it out. And then he'll run over and grab a book and bring it over and say, "Read this book to me." And I read the book to him. And then he'll run over and bang on an instrument, any number of things. He just spends his whole life experimenting and trying stuff because that's what life's about. It's joyous.

And somehow, between ages 2 and 42, we sometimes forget just how fun it is to learn stuff. And I'm going to take that a step further. I would argue that the definition of fun is learning stuff. Looking again at my two-year-old, what's fun for him is to go and experiment with stuff, right? Play mad scientist [chuckles] and try stuff and see what happens. Because there's that thrill of wondering what's going to happen, wondering if what you thought would happen is what's going to happen.

If I were to express it in scientific terms, grown-up terms, he's wondering if his hypothesis or wondering if his model accurately represented the world. And if it doesn't, like, oh, cool, I was wrong. What can I learn from that? Now I have to revise my model and understand the world differently. That is fascinating. Fun is about trying stuff and seeing what happens. And, you know, as adults, we say, "Oh, I want to have fun. I want to go on a vacation somewhere to someplace new." And we do that because we want to go see someplace new. We want to go learn something we didn't before.

What's boring is doing the same thing day in and day out. I think that fun, by definition, is learning new stuff. And if we remember that, remember that learning is fantastic, [laughs] it's what we were born to do, then it kind of changes our perspective. And it also changes the way you study. Rather than thinking that everything has to be formal, go help with an open-source project, right?

Go do something that interests you because that'll keep you engaged and get you through the tedious aspects that are part of learning anything. You know, sometimes it's a lot of repetition. Maybe always, it's a lot of repetition. But if you're doing that in order to, you know, climb up to a higher plateau, you know, if you're climbing a mountain, there's a lot of climbing before you could get to that plateau. But we do it anyway because we want to get to that higher vista. There's my answer.

KYLE: While you were talking about that, I was thinking about, you know, how this paralleled into our fields. And we'd been talking about cattle earlier. And, with DevOps, we've already discussed how fast that's moving, that kind of, you know, same thing. You kind of have to enjoy the new stuff, right? And you have to not get attached. You can't really get attached to a specific brand or a software or even a library.

It's one of those things where you might have maybe deployment software that is just the bee's knees right now. But here, in two months, there might be something that completely stomps it in features. And being attached and not willing to pivot to that new software is just something that will hold you back in your career. It'll hold back your company, your team, you know, it'll just hold everything back. You're not willing to go to the new product and explore that and figure out, you know, is this better for me?

It made me think, too, as you were telling your story about your son and stuff, you know, I'm sitting here drawing that parallel. Even the stuff that you're interested in...I'm sitting here thinking about disc golf. When I first got into disc golf...and I'm not sure how many of our viewers can relate here. I'm hoping that...I'll call it ball golf or just normal golf, has the same thing with the different drivers and woods. And I don't know the terminology very well, that's why I'll stick to the disc golf.

But it's one of those things where, you know, you're learning, and it's super fun. You know, at least in my mind, it was super fun. I'm getting better, you know. And what kept me interested was figuring out, oh, what do I need to change about my form? What do I need to do here? And regardless of anything, there's new discs coming out all the time that just have different flight patterns, different characteristics. And it's like, oh, well, I need to go try this. I need to go try that.

Some of these things are not going to be better. And some of these things might even be repeats of what you already have in your bag. It's not uncommon in the community to have hundreds of discs, you know, at least tens of discs. And it's like, well, how many do you carry on to the course? Well, you know, 10, you know. So you've just got a bunch of these that are laying around, but you've wanted to try them. You've had that investment because it's something you're interested in.

And I feel like software is that same way, you know, maybe the new tech doesn't give you anything that you need, but maybe it will. Maybe it's something that you want to put in your bag of tricks going forward. I think that analogy and just pointing that out is really kind of cool. In my mind, I hadn't really drawn those parallels.

TAD: As we've been talking, I've actually...suddenly, I've been reminded of a really excellent presentation by one of my friends named Brandon Hays that did at RubyConf (I forget which Ruby Conference. I've gone to a few.) about surviving the hype cycle. And in it, he talks about the different stages of, like, software and the different types of people that are attracted to each stage and compares it to, like, settling the Old West.

So, when you're settling the Old West, first of all, you had, like, the trappers and the explorers that just went out and kind of found stuff. Nobody knew what was out there. They went out. They lived by themselves. They were just thrilled by discovery, and that's great. But then you needed people who would come along and build roads. Like, you'd need people to come along and map these places that they'd heard about and say, like, "Okay, we need some ways for some other person to get there."

And then, eventually, you had, like, your small settlement and people who were good at, like, setting up the small settlement and clearing the trees and things like that. And then you had the people who would come in, and it's like, okay, now let's make a proper society, and have laws, and roads in our city and things like that.

And I know, for me personally, I look around, and I see something like, oh, there's yet another new JavaScript framework out there. And, oh gosh, like, [laughs] I don't know if I could keep up with every JavaScript framework. But there are some people that love that stuff. And I think trying out the new things and trying out the new framework, and those explorers, right? The people that move in and like to figure things out.

And I've discovered about myself is I'm probably not that guy. The idea of keeping up with every new JavaScript framework makes me feel a little tired inside. But I'm maybe, like, a generation or two past that where I'm like, okay, I'm not looking at every new thing. But now that there's a few established frameworks, maybe I'm going to look at Vue versus React and see which one I like better. That's what I'm going to learn, and that's what I'm going to do. And then maybe come back and tell my team about my opinions about that sort of thing.

And there's some people that are like, you know what? I like to be at the tail end. I like the boring technology. I like, you know, my old reliable Java framework or whatever, you know. And that's great, too. For me, the challenge was figuring out what type of developer I am and sticking in that lane and not feeling bored by the old and boring, which to some people is great. For them, it's like, familiar, and this is what I'm familiar with. And this is what I'm an expert in, right? And feeling overwhelmed by the new and shiny.

And I found that I fall somewhere in the middle between the two that if you find that spot along the continuum that appeals to you, then it's a lot less challenging, I guess because you kind of found your fit.

MIKE: That's interesting, talking about those groups of people. Because in every one of those groups, there is room for fun, for experimentation, for discovery.

TAD: Right.

MIKE: You know, you could be the person out discovering new peoples, and landscapes, and geography, and [chuckles] oceans. Or, you could be the person many generations down; you're the plumber who's figuring out every day how to make those pipes work because every situation is a little bit different. And both of them involve discovery, novel situations, creativity, learning something new every day. And they both have value. And they both can have fun. And finding the fun within those different fields is kind of how you grow your career and find the joy in it.

KYLE: Kind of the breadth versus depth concept. You kind of need all of those kind of people in software clear through the span, you know. I'm sitting here thinking and, like, kind of what we're saying here, like, I'm almost going into a phone analogy just to kind of describe the different people.

And I'm thinking, you know, there's those people that they need the new iPhone. Every time a new one comes out, they need the new one. And then there's those of us that, ah, my phone works. I don't need to upgrade for four or five generations. Then there's those people that, you know unless it gets an improved camera, or unless we get a new cell technology or something specific, some special feature about it, they don't want to try it.

And then there's those people that, like, oh, that's a cool feature, but I'm going to give it a few generations to mature. Like, I don't want to be on the bandwagon. I'm the beta tester testing out this new feature. I want it to mature a bit.

And there's just these people, I mean, and that goes into the software too, the libraries, you know. Maybe it's, you know, a language. I got to use the new language. No, I don't want to use the new language unless they have something special that I need. Well, maybe it's a library. You know, you can kind of drill down. And those different aspects, those different tiers, are going to be exciting for different folks. And you don't have to be all in on one way or the other.

TAD: So, I've got a question for you, Kyle. I think it was you that mentioned Rust. Do you feel like, oh my gosh, I've got to go learn Rust, or else I'm going to fall behind, or else I'm not going to keep up? Or is Rust something where you're saying, like, okay, that's really interesting. There's other people who are developing a bunch of stuff with Rust right now. But where I want to be is, you know, maybe I'll wait until the DevOps tools have matured a little bit before I look into Rust. Or maybe you're like, that's awesome, but I'm just not going to worry about Rust at all.

KYLE: If you're asking how I'm feeling about it from my computer engineering background, I think it's very interesting, you know because I came up developing in C. And I would like to get into it. Have I done much with it at all? No, no. It's very interesting tech to me. But I'm very breadthed [SP] in what I'm learning in DevOps. There's a new monitoring tool every week. There's a new way to, you know, utilize monitoring every week. And so that's where my focus is.

It's one of those things where when the tooling comes, I would be happy to try out some of those Rust libraries. But it's not something I'd personally be into. I know that there's just people that are, you know, stumbling over themselves to get in there and learn it as fast as they can and get new libraries written. But yeah, I mean, that kind of goes into the topic. What's your interest? What's fun, and what do you have time for?

TAD: So, is the takeaway find the thing that you enjoy and find the niche where that fits, rather than trying to feel like you got to keep up with all the things all the time?

MIKE: If you think that you can keep up with all the things all the time, I'm sorry. You've got a rude awakening coming. [laughs] You know, people talk about finding your passion, thinking, well, I got to find the thing that I love. I've read that that's maybe a little bit misleading. You need to find the thing that you're willing to do even when it's a struggle. That's what you care enough about.

What's the thing that you're willing to keep doing, even when it's hard? And if you've found that, then you've found your niche. You've found your place that you can thrive because you're willing to keep working on it because that's fun. The cost is worth it to you.

TAD: Yeah. And I'm asking these things a little bit just because I've talked to kind of newer developers, and they often do feel overwhelmed. They're like; I'm starting my career. I don't know if I should commit to something or not. What if I commit to the wrong thing, and I totally miss the boat? And I become an expert in outdated technology and, you know, I can't put food on the table for my family, and I can't find a job. And, like, these are, I think, real concerns, but there are still COBOL programmers in the world, right?

KYLE: They're high-paying right now, right? Because there are so few of them.

TAD: Yeah.

MIKE: And, even further, if you go and become an expert in a language, it transfers over. Most of those skills transfer over to a new syntax. The skills that are most important are at a bit higher level than that, above the language. Now, of course, knowing the intricacies of the tool you're working with is important. But you can spend a lot of time developing a skill in one tool and then transfer over to another one and get up to speed pretty quickly. Because, you know, architecture, and design patterns, and, you know, understanding data processing and best practices are not going to change from one framework or language to another.

Talking about my two-year-old running around, seeing what he can take apart with a fork, is probably not going to directly translate to what he's doing in his adult life. But the motor skills that he's learning, understanding the physics of how things work, you know, understanding of materials is. [laughs] Understanding the difference between a piece of metal and a piece of sheet rock that matters. And he just needs to be trying something. And I think that that applies to our career as well, go out and try something. And the skills may not directly transfer, but they'll probably still help you.

KYLE: I'd say, too, don't be afraid to pivot at all. Because just my example in my career, you know, I wanted to go into hardware. Well, I learned about software, you know, and I wanted to be a developer. Well, I went up the QA track. I really liked the QA track. I landed in DevOps, and I really love DevOps. You don't know what you don't know until you know. [laughs] There's probably a better way to state that. But, like you're saying, try everything, and don't be afraid to explore.

MIKE: Eddy, in particular, I don't know that we've heard from you yet. Did you have anything you wanted to share about challenges that you've worked through in starting your career? You're kind of at the beginning of your career, so you might have some interesting stories.

EDDY: The initial difficulty for me really was just trying to hash out whether development for me was the right career path. In the beginning, I jumped around with ideas. I'm like, oh, I want to be an artist. I want to be a psychologist. I'm like, huh, well, maybe I think it's time for me to really sit down and see what is the most viable option for my future, something that I can sustain a family?

I landed upon development, but even then, you don't know if that is something that you're passionate about until you, like, sit down and really, really start hashing it out and see if that's something that's really for you. So my difficulty in the career that I've started was if this is something that I...was really something I was cut out for or not. And once you get over that hurdle, and you realize, huh, yeah, maybe this is for me. Maybe this is something that's worth my time to be invested in and get really good at. That, for me, was the most difficult hurdle.

MIKE: You say you tried it. [laughs] And if you hadn't tried it, you wouldn't have known.

EDDY: Exactly.

MIKE: There's a recurring theme today of experimentation, play, [laughs] doing new things. And you learned by trying. Sometimes that's intimidating because, like, well, I don't know if this is going to work or not. Maybe it won't work out. Well, maybe it won't, but you're never going to know unless you try.

EDDY: It also helps to be surrounded by people who do the same thing. The hardest thing for picking up new talent is having the discipline to keep going. And being surrounded by individuals and constantly communicating with everyone really helps to fuel the fire.

MIKE: Definitely. Find people who are good mentors [chuckles], and it will make a huge difference.

KYLE: I would just quickly point out, too, that Eddy was saying that he wasn't quite sure where he wanted to focus; you know, he's interested in art, and I think he said psychology. And the one amazing thing that I've seen with software is it's cross-industry. This is something that if he finds that he really, really enjoys software, he doesn't have to give up on the art or the psychology. He can find software where he's doing art, or he's focusing on psychology, you know if that's a route that he wants to go.

EDDY: It could be argued to some extent that code is art. And there's also some psychological aspects to development as well. So, like, some of those attributes did kind of play its [inaudible 41:44] role in my career as well.

MIKE: There's a great deal of art, I think, in any trade and in software where you're building things from nothing, and it's dramatically so. And it can be fun.

EDDY: Do any of you ever look at a file with the code being written, and you're like, "Oh, this just looks beautiful?" And, like, to some degree, we're comparing that to art. And you're like, "Ah, this reads beautiful." This looks beautiful. You know, we're comparing it subconsciously, you know, to some sort of art.

MIKE: When I see a well-written unit test that's wonderfully clear, has excellent contexts, covers every branch of logic, doesn't go beyond the boundaries, just excellently follows best practices, I look at that, and I just grin. [laughs] It resonates with me. I like it not just from a professional sense but aesthetically; I find it wonderful. [laughs] Absolutely, I see beautiful code.

KYLE: I would say, too, that I feel like I find voice in code. And what I mean by that is once I've worked with developers long enough, I can look at code, and I can be like, oh, XYZ developer wrote this, you know. And you can kind of see kind of like an author would, right? You'd be like, this book is obviously written by this author. If that translates into code, too, it's kind of interesting.

EDDY: Actually, I want to ask point blank to everyone here, thus far in your career, can you genuinely read a file and just be like, oh, this is the flavor of Kyle? Oh, this is the flavor of Tad? I know because he enjoys using rockets versus --

KYLE: Well, and that's what I'm talking about. I feel like if I'm around an engineer long enough, I can definitely do that. I can just look at the file, and it's like, oh, yeah, Adrian wrote this. I know who did this.

EDDY: That's awesome.

MIKE: Absolutely. [chuckles] It's interesting. You can see the stamp of the artist. We started from what are the challenges to hearing about the distinctive style of the artists at their work, that as you grow, you get good enough that you actually leave your own fingerprint on things. And maybe that's a good place to stop today, that you can get to that point. That even though you're going through struggles in your career (You'll run into those times that feel dark.), it can become a joyful artistry that people even recognize your fingerprints on.

It's been great talking today. We look forward to next time. And I'll see you next time on the Acima Development Podcast.

Software development is largely an exercise in frustration management. And that is genuinely fundamental to what we do as software developers. How do you manage frustration as a dev?

Transcript:

MIKE: Hello, and welcome to another episode of the Acima Development Podcast. Today, we are going to be talking about frustration management. And you might think, well, what does that have to do with code? [laughs] And I'm going to say that it has almost everything to do with code. Software development is largely an exercise in frustration management. And that, I think, is genuinely fundamental to what we do as software developers.

We solve problems, and we have to deal with our inner self, you know, with that inner voice as much as we are dealing with anything else because, you know, that's the tool that we have. We have our minds. And if we're not in control of our emotions and our minds, then we're not going to get much done. I feel like frustration management is genuinely central to being able to be effective as a software developer.

I wanted to start with a story. As we were preparing for this, I wanted to share something that was genuinely frustrating for me. A number of years ago, I was tasked with working on a project. Specifically, there was communication. There was messaging not working between two systems. And the library we were using to message between the two systems had a few interesting attributes. [laughs]

First of all, it was designed to run in a separate thread, so it kind of ran in the background. It actually did not only run just one thread, but it ran a pool of threads, which meant that there were several different parallel threads of execution running, so it was concurrent. There were several things going on at the same time.

Secondly, it was distributed because there was more than one system. There was more than one system that was involved that we were listening to. And you could actually have multiple different processes listening or multiple threads. So you had concurrency at both ends, and it was distributed.

And third, it was asynchronous. These messages were sent over a message queue. They arrived kind of when they arrived. So there was no guaranteed delivery time. So it was concurrent, distributed, and asynchronous. And if you've ever tried logging something that is across multiple systems, [laughs] that has multiple threads going at the same time, you may find that it's quite challenging. It is remarkably difficult to find out what is going on there.

And, further, the system that I was testing had unit tests that didn't work. They were written for a different messaging system, and they just didn't work with the one we were using. So the tests I had didn't work. The messaging layer was sometimes a little unreliable. The code I was working crashed randomly, and I didn't know why. And all of the kind of standard tools for debugging or logging were somewhat ineffective because you couldn't really figure out what you were latching on to.

Also, I didn't know it at the time, but the library that we were using had several critical bugs in it. [laughs] I thought that I was solving messaging, but I was actually solving a bunch of problems at once. And I came in excited. I was recently working at this company. And I wanted to kind of show that I knew what I was doing, spent a day working on this problem and got nowhere, and felt really deflated at the end of the day. Tomorrow will be better.

And the next day, the same thing happened. [laughs] I spent all day working on it and got nowhere. And I thought, well, tomorrow I'll get this. And that happened for almost a month. Every day, I tried a new thing. And every day, I left defeated and had to come back and push on it some more. And what I did was I just tried lots of different things. Every day, I would try something new or maybe adding different logging. And, over time, it was imperceptible. It was imperceptible. But I started to see where the problems were.

Eventually, I found one bug in our library and got that fixed from the library creator. A while later, I found a bug in our code, and the way it was using the library was causing multiple threads to be spawned, and that wasn't good. That got fixed and made it a little bit better. A little further, I found another bug in the library and solved it. I still hadn't solved the problem. The messaging still wasn't working. But by pushing at it, those incremental changes actually got me a little bit closer.

Finally, I decided to redo the way some of the unit tests were running, and I got through the unit tests and got those working, which allowed me to progress. After about a month, I finally got all of the problems solved. And it worked. That library went on to work, essentially without thinking about it for years because I'd taken the time. It was a very painful month. [laughs] That's probably the most challenging project I've ever worked on because it's just so inscrutable. But I got through it, and it was worth it in the end.

I share that story because, hopefully, [laughs] it reveals some of what's going on, and it's just kind of some personal confession here. But yeah, sometimes things are hard. I talk to my kids when they're working on things. They get frustrated. And I tell them that there are three things that they should do. There's three specific skills that I teach them that they should use when they get frustrated because frustration happens. Helping them with school, helping with their schoolwork, they're going to get frustrated sometimes.

So I tell them three things to do. These are things that I give to my children, but I think that they're very applicable to adults as well. And the three things I tell them that they can do, and I'll ask them, say, "You know, you're feeling frustrated. What can you do?" And then they'll pause for a second, and they'll give me ideas, and they'll choose one.

First, they can stop and breathe deeply, close their eyes, and breathe deeply. You may refer to this as meditation. It is the process of stopping, calming down, just listening to your breathing. It may sound like a little thing, but it makes a dramatic difference. It makes a surprising amount of difference in your mental state. Separate yourself from the work and just focus on your breathing.

The second thing I suggest to them is exercise. Step away from here, [laughs] your work, and exercise for a minute or two. Some people go for a walk. My kids will often do jumping jacks or run up and down the stairs a few times. And getting blood to your brain has lots of evidence behind it, as giving you some added oxygen and probably glucose. It sends your brain the things that it needs to kind of freshen up and be more clear.

And the third thing I tell them is go do something different. If you're really frustrated on something and you hit your head on the wall, go try something different. I find those things are very helpful.

I've got a number of other ideas as well. I wanted to lead with these ideas, though, because I think that it's really helpful to have something to start with. So, what are your thoughts about this idea of frustration management? And did those suggestions resonate with you? Or do you have other ideas that really work for you?

MATT: I feel like stepping away is key because we face these frustrations every day and repeating the same thing over and over with the same result they call insanity, right? So I feel like stepping away is one of the most important things that someone can do. It helps you gain a little bit of clarity. And you never know when those aha moments are going to come. But I have found that stepping away, thinking about something else brings those aha moments, personally.

MIKE: But it's sometimes hard to step away, isn't it?

MATT: Oh, absolutely. Because you don't want to feel defeated.

KYLE: I've got several different levels of stepping away. I'll get up, and it's maybe just a change of scenery for a second. And you stare out the window. And it's got to be some type of movement for me, at least. Even doing that for a couple of minutes and then coming back will relieve some of the frustration and help me think better or going on a walk.

Even changing a scenery, you know, in the sense of changing the environment where you're pairing with somebody that seems to help too. The other thing is just stepping away in the sense of working on something else for 30 minutes to an hour or so just to kind of do a mind dump and then go back and see if you can figure it out from there.

EDDY: I was just going to add to Matt's aha moment. Like, I live for those moments personally, and that's what makes, like, super, really fulfilling. [laughs] It's great when you can get unstuck. But talking about what Kyle just said, I think change of scenery is super key, whether that's, like, walking your dogs. Like, that's what I do sometimes. Like, I'll take a 15, walk my dogs, and I'll play with them, play catch. And then, when I come back to the computer, and I look at something, I'm like, well, duh, that was the problem. But it's really hard to see that, you know, when you're tunnel-visioned, so, like, getting a fresh view coming back really does help.

MATT: I think that's a great point. Another thing is a different perspective helps me often, if possible, right? If you can reach out to one of your peers and get a different set of eyes on a problem, I find that extremely helpful. But I love paired programming so much because then you don't face that tunnel vision that we sometimes have a tendency to get stuck in.

MIKE: So you mentioned pair programming. I came thinking about that as well. You said that another pair of eyes can sometimes help you be less frustrated?

MATT: Absolutely. As engineers, we sometimes get into habits and form patterns of how we solve our problems, and they don't always work. But having another person there to talk it through with and give a different perspective can be so enlightening.

MIKE: And sometimes people feel like if somebody else is looking at them, they're going to feel bad about themselves and feel more frustrated. So, why do you think, Matt, you said this other perspective is helpful? What do you think is so relevant about pairing that will make it better, even though there's some possibility of social stress there?

MATT: Absolutely, there's social stress. But I think that the more we practice it, the less that becomes a problem. At some level, I think we all have some insecurities and don't like to be judged. But if we can get beyond that feeling of judgment and get to a point of openness, the level that it can help you and the rate at which you will succeed becomes so much greater. But that is, as you say, that's another level of frustration that we have to overcome initially, I think. And sometimes that is hard.

DAVID: This is a kind of beautiful series of thoughts that are stringing together here for me that, as I was thinking about the podcast topic, I actually came to the call ready to say, "Oh, my secret technique is get therapy." And I laughed at myself. And then I thought, actually, that's kind of a serious idea. If anybody here has ever been to therapy, your therapist will do two things: They will either help you increase your capacity to deal with what you are doing, or they will teach you situational tactics to deal with the specific stresses you are facing right now.

And what are we talking about here, right? Get up. Go take a walk. Get some exercise. Get some oxygen. Increase your capacity to handle what's in front of you. And then situational tactics, right? Find a way to disconnect yourself from the stress. Take a break. Walk away. Talk to someone else. Find some psychological safety. This is blowing my mind. It's fantastic.

MIKE: There's a recurring theme in lots of conversations we've had here in the podcast that a lot of success in software development is not necessarily about technical skills. A lot of it has to do with your team and their willingness to grant you the psychological safety you just mentioned. It's easy to think, well, yeah, I'm really good at coding. That's not necessarily [laughs] the defining characteristic that's going to lead to success. But rather, it's going to be that collaboration with your team, the ability to have psychological safety, and let people feel safe when they come to you with a question, and they're stuck because we all get stuck.

MATT: That's a really good point. I think one of the things over the course of my career that has leveled me up more than anything is working on my communication skills and learning how to listen and not talk over people. That's one of the things that I really work on and sometimes still struggle with. But just working on that problem with myself has helped communication immensely.

And when you are able to communicate with your team, and your peers, business, and your customers, I think you level up really quickly. And, ultimately, I think that's all of our goal, right? Is just continue to level up in our career and our personal life and become better.

KYLE: I was thinking as we were talking through this that half the time when I'm pairing with somebody or reaching out to somebody, it's more of just a teaching experience, I guess, to some extent. And that's where I've found a lot of the success in pairing and figuring out a problem. And so that, like, reaching out to a team member that maybe has no idea about the topic, and part of the way through explaining that, I'll be like, "Oh, this is a solution, right?"

And even so much as in, like, I'll be frustrated and go and try and explain it to my wife where she's not as technically savvy. So I have to put it in more layman's terms. And just the process of putting it in layman's terms, you either solve the problem, or it becomes more apparent to you what the issue might be.

MIKE: That process of explaining is amazing, isn't it? [laughs] It reveals all of the...maybe not all of them, but it has a tendency to reveal all the cracks in your thinking, all the gaps that you hadn't filled in, the dots you hadn't connected. It is a remarkable tool. And some people will keep a rubber duck or whatever other toy they choose on their desk to talk to if they don't have somebody to talk to, just so they can explain to somebody. That idea of explaining is so useful.

What other things do you all try to deal with your frustration?

KYLE: I'll just throw out music therapy. I've got different levels of different genres of music that I will go through as my frustration builds. Sometimes that tends to help as well.

DAVID: Ooh, riffing off of that, somebody taught me a technique in middle school that blew my mind, specifically how to use music therapy. Like, if you're in an awful mood and you're just like, well, I've got this library full of...this playlist full of, you know, thousands of songs, how do I fix my mood with music? And he told me the secret. He said, "Go find something in your playlist that matches your current mood and play that, and sync up to it. And then start moving towards music that represents the mood you want to be in."

And it was that idea of, like, find the music that matches you right now that was, like, the aha moment for me because, like, if you're furious, then, you know, some calm classical is...you're going to spit it out. You're just, like, get away from me with this. So I have a lot of playlists that start with, like, Rammstein and go towards Mormon Tabernacle Choir by the end of it. And it's a pretty eclectic playlist but profoundly useful.

MIKE: It's interesting that music is mentioned. It's another change of environment. The change of environment just keeps on coming up as well. [laughs] Change what's around you. And music is one very active way to change that environment, much like stepping outside would be.

DAVID: The nice thing about Utah is we are about 20% relative humidity right now, which means we can walk out when it's 20 below, and you can be in a T-shirt. And you can make it pretty much to the end of the block and back before, you know, serious complications set in. A lot of my friends that are out in, like, you know, Illinois and, you know, Ohio where it's, you know, 90% humidity all the time, they're, like, "You stepped out onto your porch without a coat on? What's wrong with you?"

MIKE: We've talked about this change of environment and literally changing your surroundings or what you're listening to. One thing that I find very useful is more figuratively stepping back. When I've been figuratively banging my head against the code for a while, one thing that I find works tremendously for me is to take a figurative step back, maybe a literal one, you know, step back from the laptop. But, figuratively, to start, in my mind, looking at the bigger picture.

One thing I find is that when I'm very frustrated, it's usually because I'm running into something that doesn't make sense to me. And if something doesn't make sense, it's often because I'm missing the broader context. I'm looking at something too closely, so I don't see what external to that little piece I'm looking at might be relevant. I find that when I'm stuck when I'm in some sort of hole that I can't get out of, what I need to do is kind of step out of the hole, right? And look at the bigger picture.

Well, maybe this doesn't make sense because I'm thinking about the problem wrong. And when I go and look at the surrounding code, look at the...re-evaluate, challenge my assumptions, it can make a tremendous difference. And maybe sometimes the change in the literal environment is conducive to that because you're looking at something different.

When that's not an option, and even if it is an option, a lot of times, I find it very useful to take that alternative approach, think, well, this doesn't make sense, which means I'm probably thinking about it wrong. Because if it doesn't make sense, if I'm frustrated if I'm just hitting against it, I'm probably thinking about it in the wrong way. Taking a step back makes a big difference to me. Have you found in your personal work that that is an effective technique?

DAVID: When I remember to do it.

KYLE: That makes me...I had a manager a few companies back who introduced me to mind mapping. And I don't always start out with that, but when I do get stuck in a problem, I will start mind mapping. And how this relates is when I get so far down a path, I'll either take a step back and see, like, maybe I missed a path for a solution, or I just wasn't thinking that specific section through far enough. And I'll keep going back to see if there's a neural path that I maybe have missed. And that has helped previously. That'll get me out of the weeds a lot of the time, actually.

MIKE: What tool do you use to write out that mind map?

KYLE: Pen and paper, to be honest with you.

DAVID: Yes, I was waiting for you to say one of the 20 different mind-mapping tools that are out there. But every electronic mind mapping tool I've ever found demands that you start at a route, and you descend acyclically down from the route. And I was taught to mind map with pen and paper. And my mind maps are cyclical. I will draw a point, then another point, then a second point or a third point, and then I connect the third point back to the first. And now you've got a cycle.

When I'm trying to think my way through a mind map, I will doodle the connections that I've drawn between, like, I will darken this connection because it's stronger. I will circle this node more and more and more and underline it because it's more important. And I just kind of let the pen wander over the mind map, adding nodes as I see fit for them. So, Kyle, I'm your kindred spirit on this. Technology has not been able to solve this problem. They've damaged the problem to make it tractable.

KYLE: Yeah, I haven't had good luck with a software-based mind map. The only one that I could say has provided me with better results, especially in a team-type mind mapping, is whiteboard just because, you know, kind of like you're doing adding the different colors and everything. I guess you could do that with colored pencils, but I've never done it that way.

MATT: There's something to be said about low-tech. You know, in this high-tech world that we live and work in, sometimes low-tech is the answer.

MIKE: So maybe changing your environment from the computer you're working [laughs] on to --

DAVID: It can be.

MIKE: Doing something very tactile follows right along the lines of what we've been talking about?

MATT: I think so.

DAVID: It's important to note that it's not just a matter of, like, sometimes the old ways are better where it's, like, well, no, the modern way is clearly better in every possible way. It's more, like, a case of anybody that used a cell phone around Y2K time period; your calls were much, much clearer than they are now. There's a reason for this. And that is because the cell system 20-25 years ago was analog, and you had infinite fidelity on the signal strength.

Now, as you get farther and farther away from the tower, your signal starts to degrade and starts to fall apart and whatnot. And as the cell companies wanted to make more and more money, they cram more and more calls into the same amount of bandwidth, which means they have to compand, which means to degrade the signal of each individual call to make it fit in a thinner slice. And so the calls get more and more digital, and more digital, and more digital.

And I remember especially, like, in the mid-noughties to late noughties, it was hard for me to use a cell phone because people sounded like rubber ducks. Everyone sounded...people would just quack over the phone. And it was because they had gotten too aggressive. They had cut everyone's bandwidth down way, way, way too far. And they had to back off and say, "Okay, we have to provide more bandwidth to get more calls. We can't just keep degrading signal quality to make this work."

That's the thing with a pen and paper. It's not that it's low-tech and that brute force is the better idea. It's that it's infinitely analog. You can do things like darken a line or change a color. I guess you can change color in a mind mapping tool. But being able to switch pen types, being able to change the tactile input that you get as you write something, being able to move two nodes the exact distance apart that you want them on the page in infinite increments of analog precision, rather than having to just put this node under this node on the tree and it always must be down one line and in two spaces, yeah, it's so much more freeing to have that much more power.

MATT: The nostalgia of the old analog phones that you had to strap to your belt. But the best phone I've ever owned in my entire life was an old Sony analog phone that was the size of a brick. [laughs]

DAVID: So I've kind of pulled us off into nostalgia a couple of times here. But circling back to the specifics of frustration management, I do like the idea of changing the environment. Internally, we can change our environment as well, I think, which is that if you're sitting at the machine and you're stuck...Mike, I've been in that problem where you've got, like, you talked about the messaging system at the start. You have no idea how the system works. You have no visibility into how the system works. You have no control over the functioning of the system.

All you can do is sit outside the black box and just cast things onto the water and hope the output will eventually be different whenever that asynchronous stuff finally, finally comes in. And, like, all of these things kind of stack up to put you in...I don't want to say an abusive environment. [laughs] I don't want to use that word lightly. But it is kind of an environment where you're stuck. And you can get yourself into this kind of stuck thinking where it's like, oh, this is terrible. I'm trapped. I have no resources. I can't get my job done.

Oh, in addition to the no observability, no debugability, no, you know, da, da, da, there's also no mercy if you don't get it fixed. So we're going to just keep ratcheting this up until you make it work. And you can feel shackled to the machine. And just, like, ah, how am I going to make this work? Sometimes being able to step back and go, all right, guys, it's just a computer. Let's breathe. There's only two ways this bit can go, either one or zero. How do we reduce this problem?

Finding a way to step back and give yourself some control over your environment or just control over yourself can be immensely liberating. And it can open up to you a lot of tools that you had on your belt the entire time, but you kind of get blindered. You stop thinking that, oh, I can deal with this, and you suddenly...half your toolkit has vanished because you're not present to it anymore.

I don't know; I feel like I'm babbling. Does this make sense? Where, like, you don't feel trapped and stuck on the machine? Suddenly, all the things that you could have done all along but didn't know suddenly you remember that they exist. I don't know if anybody else has had that experience, but it has for me.

MATT: Yeah, freeform, right?

DAVID: Mm-hmm.

MATT: I, as a hobby, and in a past life early on out of high school, was an artist. And I'm kind of relating to that and the digital age where I feel so much more free using real paint or real pencils versus a tablet to create art. Yeah, there's so many things you can do with technology. But there's something about that freedom and the feeling it gives you doing it the old way. It just...it frees the mind, I think.

MIKE: You know, I might expand on that a little bit. The recent surge in generative models used for AI art [laughs] was triggered by some pretty interesting realizations. Previously, there was always an effort to kind of start with something and get to something. [laughs] You got to follow these sorts of rules, or you've got to match this thing.

And they decided to try a new technique. What they did is they took an image and then they blurred it a little bit. And then they trained a model to deblur it. You know, add a little bit of noise to the image, some visual noise, and then train a model to deblur it and get back to the original. And then, you add a little bit more noise and see if your model can get back. And then you add a little bit more noise. And they do this, you know, with millions of images. They add a little bit more noise, and a little bit more noise, and a little bit more noise. And then you bring it back to the original.

Eventually, they just start with pure noise and some text [laughs] and say, "Bring me back to what this image is." And, in previous models, it had always sort of fallen flat. But this approach where you gave it a completely blank slate, right? Just start with noise and make this look like a duck in a captain's hat. And the AI looks at it, and, like, okay, well, I think I maybe kind of see a duck over there, right? [laughs] And it starts inventing.

And, eventually, you get a photorealistic duck with a captain's hat. That approach of going back to perfect, you know, as you said, Matt, freeform, where just, you know, start from scratch. Starting with a blank slate ended up being far more effective than other techniques had been. It doesn't even just work for humans.

MATT: And I love that.

DAVID: The thing I love about the AI things is when they frame it in a style. So they'll do the make me a picture of a duck in a captain's hat, but do it in the style of a 1960s tobacco billboard. And it produces something that is terrifying. You're just like, oh my gosh, that totally could have been on the side of the road in 1964.

MIKE: [laughs]

MATT: I have spent so much time playing with those things.

MIKE: [laughs]

MATT: All of these lead us back to those frustrations. And, as we talk about this, maybe that's one of the answers is find something that you find joy in to help with that frustration. The bottom line is letting it go and, I think, accepting it.

DAVID: Resignation to your fate. It's a little fatalist, isn't it? But, yeah, accepting what we have in front of us.

MIKE: And I think there's something very liberating in acknowledging reality as it is. And, in fact, I take that further. We've been talking about arts a bit. I'll talk about another art example. I'll talk about Shakespeare. Shakespeare is considered, I think, widely to be the greatest writer in the English language. And one thing that's interesting about Shakespeare is that he had, like, one hand tied behind his back. Because, generally, the form that he was expected to write in had some fairly rigid rules. It had to have a certain number of accented syllables per line. Typically, it was rhyming, right?

So the language that he was constrained to use was a rather limited subset of the English language. And, with those constraints, he was able to create great art. And I would argue that, to a degree, the constraints themselves were what enabled him. A teacher mentioned this to me in high school, and it kind of blew my mind.

Like, oh, that's an interesting point [chuckles] that once we are given constraints, then we filter down the world of possibilities. And then there's less that you have to deal with, and you can focus in on what you can do. And that's remarkably liberating because, within those constraints, you don't have to think about everything. You can think about what could fit, and it allows you to fill in blanks with something pretty great.

MATT: And it really helps us to keep things simple. Humans, by nature, overcomplicate problems. And those constraints can really help you just keep it simple. Don't overcomplicate it. Don't overthink it, and just tackle the task at hand. And, in software, that is really important. I try as hard as possible every time I take on a task to make it as simple as possible. If it needs to become more complex as we go along, that's great. But I always find the simpler, the better, and you usually end up producing better work that way.

DAVID: I love that. There's an interesting tension here that we're talking about, like, for creativity...and I heard this back in, like, my 20s, but it's been so true. If you want to increase your creativity, increase your constraints. If you want to write like Shakespeare, tie one of your hands behind your back, figuratively speaking, right?

There's a fantastic video by Tom Scott about Why Shakespeare Could Not Have Been French. And I'm, like, that's pretty elitist. No, he's like, literally, the notion of an iamb, which is the thing you make iambic pentameter out of, doesn't exist in French. You literally cannot construct iambic pentameter in French. It doesn't work. There are other types of poetry in French that have meters that match the metrics of the French language, and French poets will follow those.

But, yeah, if you want to increase your creativity, increase your constraints. If you don't believe me, try this exercise. First, name every animal that you can think of, and give yourself, like, 10 seconds to do it. And I find I get, like, five or six out there. And then circle back and say, okay, do the same thing, but do it in alphabetical order.

And you're like, whoa, what? Somebody has said, "Oh, name all the animals you can think of," all right, fine. I'll start in the alphabet. But if you start with A, you can immediately come up with an animal that starts with A, and you get to 10 seconds, and you realize I just named 12 animals because I constrained myself. The constraint gave me structure.

The reason I mention this as a tension is that when I'm debugging, I want to go the other way. I'm already constrained five different ways. I don't know how the system works. I can't observe it. I can't debug it, can't...I don't have unit tests or whatever. What can I do to increase my options and my choices? And sometimes we don't have very many. And that's a good time to just kind of sigh and accept without judgment and just say, "Well, I guess we're going to get pretty creative because we are pretty constrained."

MIKE: This idea, I think, is so powerful, and I'll add to it. Multiple of us are musicians here. For those who are musicians, I want you to think about this. If I want to sit down and make some music, invent some music, improvise, well, I just sit down and say, "I'm going to write some music," that's an intractable problem. What am I going to do? But if I sit down and come up with a riff, just if I'm going to play on the piano, I will [inaudible 31:46] my left hand. And I'll come up with some chord progression or play something sort of melodic that sounds interesting and then start repeating playing it as a riff.

So it's something that could be in a cycle that I can listen to. Well, now I'm wildly constrained versus what I was before. Now I've got something that I have to work with that I have to fit into. And, suddenly, I can play because now I can invent music that fits within those constraints, and I can make music. And if I remember that, if I ever want to sit down and write a song, you know, in a couple of minutes, I can be improvising and having some fun by starting by limiting that world down to those constraints.

MATT: That's such a great example. I kind of do the same thing. If I am asked to just sit down and play something on a guitar, I would fumble. But if you said, "Hey, sit down. Play something. This is the mood I'm looking for," then I can say, "Okay, I can pick a key." And once you constrain it down to a key, it becomes really easy because there are constraints on how you're playing it.

DAVID: That's impressive. And various things can imply a lot more constraints, right? Like if you say, "Play me something moody," that's going to constrain things gently in a certain direction. But if I say 12-bar blues in G minor, you know the chord progression now. It's 12 bars, and you have to start on the one, and there's rules for how they come out. And so you've got your chord sequence now.

MATT: Yeah, if someone says, "Play something moody," I think, okay, A minor because that, to me, is the moodiest key. It makes it so much easier locking things down, having constraints, which, in software development, we have requirements, right? And if we don't have requirements for a problem, then it makes it really difficult to solve.

MIKE: I'm going to take this right back hard into software. We've been talking about constraints. Frustration, in the general sense, to be frustrated that word means to be stopped, to have your course blocked. And these constraints we mention are essentially that, right? They're frustrations. They're barriers. They're obstacles. And what we're saying is that those frustrations actually provide us a framework in which we can create beautiful things. And it's the existence of those frustrations that gives our work shape and even meaning.

KYLE: I was thinking about this as you guys were talking about music. I don't play, but my family had sent this YouTube video that was talking about how they did the music for the Dune movie. And, in that, we were all kind of shocked to see that the bagpipe that you end up hearing in some of the scenes they were saying that that wasn't actually done by a bagpipe. That was done by an electric guitar. They had just taken a different approach to generating those sounds.

And I think that can be related to software in the sense that you can constrain yourself but don't let the constraint be of frustration in the sense of, like, that you tunnel. And what I mean by that is don't go so far into a tunnel that you're insisting on using a specific tool. Sometimes another tool will provide you with the same result, if not a better one.

The example that I can think of right now is just on our team. The easiest tool for us to use, specifically our lead that designed the Acima script; he was very familiar with Ruby, and he was able to bust out the script in Ruby. But that didn't make it as easy to pass it around. And so, he took a different approach with another tool and used Golang. And that made it easy to distribute an executable to all of these systems.

And so much now that, you know, Apple silicon or ARM64 is becoming a more popular option. We need something for those environments. And this has allowed us, because of that tool, to now generate that software, you know, with just one or two changes. Then we have an executable that will run on those. So it's cross-platform now. Just thinking about that, just while you're constrained, don't also tunnel because that can just add to your frustration.

MIKE: Oh, that's great.

DAVID: I think approaching your constraints as a challenge as opposed to a trap or something that just leaves you powerless...something that I keep hearing come back, and back, and back as we talk about this is the notion that sometimes we look at the challenges in life with fear. And other times, we look at them with wonder and excitement. And the only difference is the attitude that we bring to it.

Looking at the inconsistencies, or the challenges, the difficulties that we face, when we see them with kind of, like, wonder, they become opportunities. They become interesting things to play with. They become flavors to taste rather than things to be pushed away and kept at a safe distance. And I think that mindset really, really makes it a lot more powerful, a lot more capable for us to kind of relax and just kind of play with what we have. And that helps us find the way out that we're looking for.

MIKE: I love that: flavors to taste. There's one other thing I wanted to bring up, and I think that it builds on that idea of joy you just brought up, Dave, which I think is phenomenal. I think the one other technique that we really haven't talked about is asking a question, what else could I try? And to your point about, you know, this is a world of discovery, if you're in a situation and you feel like, well, there's nothing I can do, well, then there's probably nothing you can do. [laughs] You've made a choice.

But there usually is something, even if it's trivial, right? Well, I could breathe differently. [laughs] That is an experiment. That is play. If you look at the problem and say, "What else could I try? Is there maybe some way I could add some logging to this that is crazy but maybe does something, or is really simple and crude, but it would maybe get some information out of this?" Or maybe I usually use a debugger. Maybe I could just use some simple text logging.

Or maybe I could add a request ID to all of my requests that I make so I can track what's going through. Or maybe I could log my thread ID so I can connect the thread with the outputs going on. There's usually something else we can do, and seeing the world as a big sandbox. What could I try next? Changes that perspective. It gives me an opportunity to keep trying.

DAVID: Amen. One of the best tools or ideas put into my quiver early, early on, was the notion that debugging doesn't stop when you run out of answers. It stops when you run out of questions. As long as you can sit back and say, "What else can I try? What else is there? Have we looked at this?" There's always more things to find out. So, yeah, when you run out of answers, it's time to loop back up a level, not to just give up.

MATT: I love that.

MIKE: That, I think, is the perfect place to kind of land here. Yeah. Thanks for joining us and for all of your thoughts. And thank you to our listeners. I hope that you've gotten some value out of these tools you can use to work through the constraints that you have and even celebrate the constraints that you're working with. With that, see you next time.

How do we work effectively with product people?

Transcript:

DAVID: Hello and welcome to the Acima Developers Podcast. I'm David Brady, and today we've got a huge panel. It's going to be awesome. We've got Mike Challis and Ramses Bateman. We've got David Solano. We've got Afton Call. We've got Kyle Archer, and we've got JP Porter with us today.

And today, we're going to talk about working effectively with product people. And we actually went and got ourselves some product people. We have Jeff Madsen and Tyson Novakovich on the call with us. So, you guys know that I like to start with just the topic of the call is the opening question. How do we work effectively with product people?

MIKE: I've seen it work well, and I've seen it work not so well. I'm going to point out that Jeff Madsen, who's here he's visiting us, and he's from outside of Acima. And so he's our guest product person today. And I've had great experience working with him on the product. So he's an example of how things work well, as is Tyson, actually.

And I've had other times where it's worked badly. For example, I worked at a place where there were product people who would spend weeks writing up lengthy technical documents were essentially unreadable and would hand them off to us and say, "Okay, can you go build this?" And then we wouldn't hear from them again [laughs] because they [crosstalk 01:21]

DAVID: And if you have any questions, read the document harder.

MIKE: Yes, that's exactly how it was. And I would argue that that's an example of how things should not go. And I think that illustrates how things should go, and the difference that I've seen with some of the great product folks like we have on the call with us.

JEFF: I can promise you, as can most people on this phone call, you do not want me writing technical documentation. That is not going to go well. When Mike says unreadable, he means it's in a completely foreign language that is not English or technical. It's in a garbled mess. And so that is not what product should be doing. And I totally agree.

So, I was thinking about how do I want to prepare for this and how do we want to move with this? And it got me thinking about one of the things that made our team the fact that we worked so well together is we kind of divided up what are the things that it takes to build good software? And we had a really strong technical team that's represented by everybody on this phone call, besides Tyson and I.

And then we needed a team that could go and say, you know, what do people actually want? What would be useful? And when I first started, Mike, Afton, I think you two are the only ones that would probably remember this. But there was a pretty rigorous every week we meet, and every week; we write stuff down in a backlog. And every week, we add more to that backlog so that next week, we can ignore what we wrote in the backlog and then do something else that was more important. Does that sound familiar?

MIKE: [laughs] Changing priorities?

JEFF: [laughs] Yeah. And I think what we all kind of accepted is that I don't know what two weeks from now is going to look like. I don't know what tomorrow is going to look like for now. So let's focus on what's the most important for today. And what's most important is, what problem can we solve together that's going to drive business value as soon as we can? Tyson, what do you think about that statement? Like, if that's product's job is to work with development and say, "What problem can we solve together today to drive value as soon as we can?" What do you think?

TYSON: I think it goes back to the...how I think about it is deciphering what the business actually wants. Because they're going to say they want this idea, like, hey, we want to improve this application throughput, figure it out. Or we want this fancy new button that does all this stuff. Can we build it? You're like, oh, actually, no, you want to do X, Y, and Z. It's much smaller pieces. In this big sweeping change, we can, you know, improve it by we as product decipher that, so that when we go to engineering and work with the developers, it's not, hey, can we build this exciting thing? It's hey, here is this idea of what they want to improve.

But then it's very much so a conversation between product and development, like, what ways can we do this? You know, we'll probably come up with some ideas of things we can change. But, I mean, developers are interacting with the code and how features work 24/7. And so it's...they'll have their ideas. And I think it's very much so a conversation between the two groups. That's kind of how I see it.

MIKE: Both of you pointed out something that stood out to me, and it kind of goes back to startup culture, to a degree, that, yeah, there might be different priorities each week, and that's not necessarily wrong. Now, maybe every week, that is wrong. [laughs] If you don't have the flexibility to change, then, you know, if you'd say, "Hey, we know exactly what we're building, and we're going to work on it for the next three years as a startup without any ability to be flexible," you're probably going to be out of business in six months.

That flexibility is vitally important when you're small but sometimes companies forget that when they're larger and that agility, I think, retains its value. Maybe you have longer time horizons that you can work with. But that doesn't change the fact that we're not very good, to your point Tyson, about building a big thing. Nobody is in any context.

I don't think anybody says, "I'm going to build a skyscraper. Step one, build a skyscraper." There's an art, and much of the art of what we do is figuring out that sequence. And I love that both Jeff and Tyson talked about that sequencing, like, well, yeah, you want a skyscraper? Great. We might need some materials. We might need a foundation. We might need some contractors to work on this. We might need some bulldozers.

JEFF: The other piece that Tyson [inaudible 05:35] great bit by bit, right? Is a lot of times, people will come and they say, "I want a button that does these 17 things." And when you start adding in here's the first thing, here's the second thing, usually by the time you get to the third or fourth action, it's good enough. We jokingly use a phrase where I work now, is it less worse, right? Like, the goal is to get things to be just a little bit better than they are. And usually, by the time you're not completely finished with a product or completely finished with development of a feature, it's good enough to move on to the next most important thing.

And when we started this call, we were all kind of joking about Mike, your time horizons, right? That you brought that up of being able to be agile and not be locked down. We were all kind of joking about how we've all worked at a company that's moved at an incredibly slow pace, and it's because we try to plan. We try to figure it out. We do one deploy a year, or we do one deploy a month. Everything is so time-driven, as opposed to user impact-driven.

And I think one thing that I appreciated most working with this team was Tyson, or I could come and tell a story, and we would say, "Here's what's happening. Let me give you some context so that we're all working from the same shared understanding." We would tell a story. We would then say, "Here's the problem with that story. And what we're actually trying to get at the ending instead of Little Red Riding Hood's grandma getting eaten by the wolf, we actually want Little Red Riding Hood to show up a little bit early and be able to save the day."

So we tell a story about a new future that we all want to live in together. And we go, okay, well, if you just want Little Red Riding Hood's grandma to live, there's a ton of ways we can get there. Let's talk about some of them. Here's an idea. Here's an idea. Here's an idea. And so then it becomes a mixed bag of here's what I can do. I can build Little Red Riding Hood's Grandma a skyscraper. And I can put her on the top floor with a bunch of security guards in between. Is that really what we want to do? Because that would take a really long time.

Or why don't we just tell Little Red Riding Hood's grandma not to answer the door? That might be the easiest thing, and that requires no building. That requires no development. But it gets us to the right outcome. But talking about all of these things collectively and saying, you know, there's a spectrum of right answers that require X amount of dev effort and time, which equates to money and a delayed satisfaction for the end user. And then there's some that are different options that are out of the box where it's just, hey, send grandma a text message to say, "Hey, I just saw a wolf. Don't open the door."

So talking about a lot of those things makes it so that the team can come up with a solution and then work together. And now you're all pulling a cart in the same direction. I think, like you mentioned, somebody goes off into a corner, you know, previous jobs. They write a bunch of technical documents, drop it off on your desk, and disappear. And that's probably the least helpful thing because you don't know anything that went on behind the scenes. Why are we even asking for this? Is this the actual problem we want to be solving? And I have 7,000 ideas that I could just tell you that if we cut out a ton of this, we'd still get to the same spot.

DAVID: Now I've got this idea stuck in my head that there's a meeting. They're going around the board to solve the Little Red Riding Hood problem. And these suggestions are thrown out. And then finally, like, the VP of engineering says, "All right, look, we've got budget for one more headcount, so start talking to me about woodcutters."

MIKE: [laughs] The nice thing about this is if you're being conscious about costs and thinking about that and what is actually driving value, maybe you could use that budget to hire somebody different because you don't need the woodcutter anymore. And, you know, you can avoid some of the trouble and hire more effectively.

I love how Jeff and Tyson talked about reframing the problem, that they both talked about telling stories and then jointly coming up with a solution. Now, the developers are going to understand the technical details and be able to come up with technical solutions. The product side is coming with a vision of what the problem is. A lot of times, the developers are kind of divorced or isolated from what users are actually experiencing. They don't necessarily know what needs to be worked on.

Product is, you know, their job is to know very much what that is. So they're bringing this tremendous value of knowing what is needed, but they don't necessarily know how to build it. And developers, on the other side, they know how to make stuff, but we're not quite sure what to make that's going to be valuable for the company. And when those two meet, then you can come up with a shared vision that is significantly better than either could come up with alone.

JEFF: To piggyback on that, Mike, I think one of the things that I've noticed, you know, we're talking about the difference between great product managers and product managers that are getting started and trying to figure out what's next for them is I think a great product manager can tell you why they're asking for something. They can say, "The user wanted a button that sent unicorns, and laser beams, and a pot of gold with a leprechaun at the end of it." But why did they want that?

They've gone in. They've spent time with the user, and they've spent time with the person who's asking for this new thing. And they can then come back and say, "Hey, development team, like, there's this pain that's being felt by a user, and they want to solve it. This is what they asked for. I have some thoughts. Here's what I think it is." But let's pause for a second and say I can tell you why.

The second thing that I think a great product manager can tell you is where does this fit in terms of the urgency, right? Like, hey, actually, this pain is bad, and it's getting worse. Something's happened where we have changed a piece of code, and now things aren't going the way we thought, or a new business requirement has come up. We have a new client. And so they can tell you why and where it fits in the priority. And then it's that joint effort to get to the how.

Mike, you and I used to always talk about there's the right way. And if we were to do this the right way where we went, like, full technical build out, build the full framework and the structure, it would probably be about this long. I think it would take this many people, you know, highest level, I don't know, ballpark. Let's think about this. And then we would talk about, okay, well, what's the fastest route?

And I think it goes back to, I mean, one of the things that always comes up, and I feel like it's a point of friction between product and development, is, well, what you're asking me to do on the timeframe I'm doing it on it is unfeasible. And I'm going to build an unstable structure. And I'm going to create a bunch of technical debt. And understanding that as a product manager is significant because things that are fragile break, and things that aren't meant to be scaled will inevitably be scaled.

I don't know how many times I have said, "It's going to be just this one customer. It's going to be just this one thing," and then all of a sudden, you turn around two weeks later, and sales is asking for ten more people to be put on the same thing. And so, Mike, we always used to talk about this technical debt is it, am I putting this on a high-interest credit card? Am I putting this on a low-interest subset? How am I going to have to pay for this debt if I'm not doing the ideal because it doesn't drive the value on the timeframe that the business needs? How am I going to have to pay for that later?

MIKE: And sometimes when you have those discussions...you mentioned the text message [laughs]...that sometimes when you're in a pinch, the right answer is maybe neither of the above options. But maybe when you understand what the needs are, there's another way to meet those needs that maybe doesn't build the right solution but doesn't build the wrong solution either but builds a minimal solution.

You know, particularly when you're in a startup-type situation, you've got a limited budget and limited time, right? If you don't move quickly and efficiently, you can go under. And coming up with a creative or an innovative way to approach the problem that maybe is unexpected can actually solve the problem without leaving much technical debt, or maybe no technical debt without building the big, grand solution that you originally envisioned.

I watched a documentary once about the famous Skunk Works Program that built a lot of the well-known military aircraft. And I'm not, like, an enthusiast, so I know not big. I mean, it's interesting, [chuckles] but I'm not going to know all of the technical details. But one thing that really stood out to me is some of the things that they did when they were building these airplanes. For example, they wanted to build a spy plane that could fly really high. And, to do that, they had to have wings that were outrageously long, and they drag on the ground.

So what they basically did was stuck a bicycle wheel onto the end of each wing and said, "Well, maybe someday we'll come up with a solution," and they never did. They put it into production, and they just put a bicycle wheel under each [laughs] of them, you know, with, like, a unicycle under the end of each the wings, which kept the end of the wings off the ground. And when it took off, the wheels just kind of rolled and tipped over and the plane took off. That's all you needed.

They had a plane that needed to go so fast that the materials used to build it would deform. And, on the ground, it was leaking fuel, just dumping fuel. At heat, it would expand, and it would close up, and the fuel lines would close, and everything would be fine. But when it was stopped, fuel was just pouring out of the plane. And they thought, what are we going to do about this? And, eventually, they just did nothing. They just filled it with fuel, let the fuel dump, and took off the plane, and when it got into the air, the fuel stopped dumping. Sometimes the things you think you're going to need you don't necessarily need.

JEFF: I really want to meet those test pilots, you know, the guy who gets into the airplane as it's dumping fuel on the ground and says, "Yeah, let's hit it." [laughs]

DAVID: I want to say I read somewhere that that particular plane takes off with about 10% fuel reserve. Once they take off, they punch the throttle and do a couple of laps and wait for the plane to heat up. And then they go refuel in the air. That was the one workaround for how do we keep this from dumping, you know, all 20,000 pounds of fuel? Just put 2,000 pounds of fuel in it until we can get it hot. That was the SR-71, right?

MIKE: I think that's right. Yeah.

JEFF: That example just goes back to, like, how do you work together to build a product that functions? You're going to go in with a bunch of assumptions. Everybody will, right? Well, I think I can do this, and I think it's going to work. And, Dave, your example is just, like, when you're talking about product development iterations through this and, like, okay, well, we know that the properties of this metal will expand. We know that this will actually close up when we're at speed. But, well, great, but now how do we get it in the air?

And I think it just is another testament to product and development we need to work together to solve the most high-value problem that's in front of you today. Whether you're at a startup and that high-value problem is we need to figure out how to make more money so the business exists, or you at a giant enterprise and you're trying to say, okay, what I'm doing is actually going to be a little bit different. It's not maybe life or death for the company, but there are things that matter there.

And there's different levels of priority, and being able to sift through those together and make things less worse, right? How do we progress together on solving the most important problem? And there's creative solutions of how do I get fuel from leaking out of the plane? Well, just don't put it in.

MIKE: And you talked a lot about priority, Jeff. Are you saying that we should always be working on the most important thing? [laughs]

JEFF: Oh, if only that were true, Mike. [laughs] If only we could live in a world where that was the ability, right?

MIKE: But, somehow, it's really easy to work on things that maybe aren't the most important thing because they're in front of us. We get myopic. We work on the thing that we're seeing rather than the thing that we should be doing. That process of prioritization you're talking about means that we actually do work on the important thing, and that is such a huge deal. And it's hard. It's hard, and it's hard to get right.

JEFF: And it's continuous as well, right? Like, we've talked a lot about airplanes. Every few months, there's this story about the Air Force was looking at all the planes that were coming back and trying to figure out, okay, where do we need to add more reinforcement for their armor? Okay, well, this one came back, and all the wings were shot up, and this one came back, and the tail was shot up, and this one came back...And we need to add more reinforcement for the cockpit so the pilots all feel safe.

And then somebody said, "Let's look and see where are we not seeing any damage because those were the planes that aren't coming back. Like, where are planes getting shot, and they're going down, and we're never getting people back?" And I think that that process of trying to ask the opposite question, trying to figure out, I see that all these planes are coming back, and they're just filled with holes. Okay, well, that's great. If you're trying to protect pilots, let's not patch all those holes. Let's go and say, "Where did they get hit, and they didn't make it?" You have to think about that. It's a deliberate action that you're trying to go through.

And listening to the users on the product side is incredibly important. But you have to listen to what they're not saying. You have to listen to what you're not seeing. You have to listen to...and try to find the rest of the story, and that is where you can pull more of the priority. And we talked about technical debt and things like that. And that's...from a product perspective, the development team that you're working with, the people that are helping you build, you need to listen to them as well. When they say something's about to fall apart, you should listen.

Like, I think that's...part of the challenge is there's lots of different theories and thoughts on how products should work. And if you're the CEO of the product, or you're the final decision maker, or you're the voice, you know, there's a lot of these things. And the answer is a little bit of all of them, right? You work with your user in the business but also work with the tech side to make sure that you're not neglecting your monthly investment in paying down your tech debt.

Making sure you've built stable code, making sure that the thing that you said as a product manager or the thing that you lied about as a product manager and said, "Only one person is ever going to use," and now there's 1,500 people using it. Is it still going to work? Like listening and pulling and trying to put all of that together and asking people, right? Like, we talk a lot about...I call it the trade-off game. Because every time you choose to do something new, you're choosing to not do something else.

And making those decisions clear for everybody of saying, okay, if we're going to take developers and put them all on these projects...Mike, you and I would talk about this quite a bit of saying, okay, this means we're not investing in our tech debt for a while. Mike, what does your gut tell you? Is that okay? You know, like, are we going to be all right? Are we going to get sunk? And then you go to the business and say, "Hey, we've ignored paying our tech debt for so long. We can't do that anymore. So I can work on this new feature for you, but that means that everything we just pushed out is at risk because it's not scaling well. It's not growing well."

MIKE: I have some thoughts about how that tech debt ought to be handled. But I'm going to pass on those for now. [laughs] I'm going to throw out there that it's good to make that credit card payment every month.

JEFF: And, ideally, more than the minimum, right? Like -- [laughs]

MIKE: Yes, exactly.

JEFF: [laughs] Yes, yeah.

DAVID: I actually have a question for you, Jeff. And some of the devs on this team will go, oh yeah, I've been there. I've worked on teams before where the product owner has come to us and said, "Here's what I want built. Here's how I want it built. Here's the problem I want to solve. Here's how I want to solve it," which should be a red flag, by the way, because it's the engineers' job to figure out how we're going to solve the problem. But the thing that we get presented from product they basically say, "Here. We need all of this," or "It's not worth shipping any of it."

And so when you come back and say, "Okay, well, can we break this down by priority?" And they say, "No, everything is the top priority." I wish that was a joke. But I really have worked on multiple teams where that was the thing. And so I'm like, well, from agile, we're going to break it down by priority. I guess what we're going to do is we're going to start at the top of the stack and just move...the priority is arbitrary.

And I've noticed that those two things go hand in hand. The backlog is on unprioritized or unprioritizable. And product is just saying, "We have to have every single card in the backlog done because, at 99%, we do not have a viable product." Help. [laughs] That's my question for you, Jeff. Help. How do we get around that?

JEFF: There's a concept...and when you said the backlog every single card has to be done, there's a concept that is brought up in a book called INSPIRED. It's written by Marty Cagan. It's, I mean, anyone who is looking at getting into product or how, you know, figuring out how to do this or how to build...The title of the book is INSPIRED: How to Build Tech Products People Love. And I'm going to take a wild swing at this, Dave, and say it all starts at the very, very beginning. When you put something in a backlog...the concept that is introduced in this book is called a validated backlog.

One of the things that we've actually done at the company I work now is we've separated out where did the ideas go, and then where did the good ideas go? Where did the actionable things go? And we spend a lot of time sifting through the ideas. We have a separate place. We have a separate container. We use a totally separate tool than what is the development backlog.

And the reason why we do that is because, from a product perspective, anything that we throw into a backlog for development that sits for more than maybe a month, I'm now questioning the validity of it. If it could sit for a month without doing it, why did we prioritize it in the beginning? So you got to go back and look at that. So going back to this other holding ground, you got to sit and think about these things.

And it's only once you've figured out, once you've worked with users, and once you've talked to them, and once you've asked them...We're actually going through this process right now. We're trying to develop...we're going from zero to one, no mobile app to a mobile app for an end user to use, a consumer-grade mobile app. Well, if you look at any mobile app, it's got your user settings, your notification settings, your preferences, your dark mode, your display, you know, there's, like, 75 things that are just kind of given, you know, my air quotes, "given" for a mobile app that arguably drive no business value.

And so what we have started to do is we're trying to get into this validated idea portion. And so we have some assumptions about what we think people would want to do most often with that mobile app that we're trying to build. And so we're building out, and we're spending time. We're saying, okay, let me put myself in a day in the life of the end user of this and say...so I work for a travel company, right?

So three days prior to me taking a trip, what would I be doing? The day of the trip, what would I be doing? While I'm at the airport, what would I be doing? Once I'm getting ready to go to my hotel, you know, so we're trying to go through and identify these core events or these key milestones in this journey and saying, what would I be doing? What would I be doing?

And we're saying, okay, I want to be able to manage...get alerts about my flight delays. I want to be able to pull up my hotel reservation really quickly. I want to be able to make sure that I'm getting my SkyMiles points so that I can get my next flight for free. There's all of these things that are happening. But when do they happen, and how do they happen? And then we actually are just creating a big list of them.

And this is where I think product rolls up their sleeves and figures this out. This is how you get to why does the problem need to be solved and in relation to what? Because we're actually going out, and we created a bunch of surveys and said, "You know, here's the seven things that this mobile app could do. How would you rank them, user?" Let's go ask 200 people. "You're a traveler. How would you rank these?"

And then the next question is, okay, if you couldn't do the thing that you put at the top of that list, like, if you have a travel app, and this sounds kind of weird, but what if you can't book a ticket? What if you can't book a flight? What other collection of pieces would provide enough value for you to download this? And so now we're getting this user feedback, and we're pulling in these stories, and we're saying, okay, I'm going to change the game a little bit for you, user. I'm not going to give you your number one thing. Would you still use it? If so, why?

And now we're starting to be able to get some layers and some nuance and some differentiation between it's not these seven things are nothing. This one thing carries a ton of weight, but it just so happens it's the most complicated. It's the hardest thing for us to do. But if we can give them these two or three things, there's still value. And we can start trickling this into the market and getting users slowly and iteratively, and adding more and getting their feedback.

And maybe that idea that we had to solve or build feature number two, number three, and number four were totally wrong. And isn't it great to know that now instead of after the 18 months we spent building feature one and then released it? So it's that validated backlog where you can go back in.

And I honestly think that, as a developer, I 100% think that it is your right, and you need to push back on product guys. I think a lot of times we come in like the Top Gun pilots, and we're like, oh, we're totally cool, and we know everything. And we're going to tell you exactly what you said, Dave, like, here's the problem. Here's how I want it solved. Here's this, and here's how you should do it, and ta-ta-ta-ta, right? Like, pushback. Call us out. Like, we're wrong. We're human. And hold us accountable.

DAVID: I love that answer for a couple of reasons. One is the idea of validation at a granular level is beautiful. Like you're saying, if you spend nine months or 18 months before releasing the product, before validating that idea, there's an extra wrinkle there, I think, which is that you're not going to validate idea number one. You're just going to assume that the entire product flopped, and you're not going to know why. Because there's 78 ideas in there, and they're all Jeff's grand vision of the 2.0. And it flopped because things weren't...you know what I mean?

JEFF: My grand vision of the 2.0 was perfect, Dave, okay? [laughs] Because I'm infallible, right? No. I totally agree. And I think that it goes back to, I mean, maybe it doesn't flop, but maybe it doesn't work. And if I've got 78 things in there, how am I supposed to know where the issue is? We spend a ton of time talking about single-piece processing, you know, isolating the change, monitoring the change, and then knowing how to react if something goes wrong, right? Like, I want to do this big giant thing, but it's a series of steps. Okay, well, let's take step one.

Going back to the skyscraper analogy that Mike brought up, like, let's dig a big hole so we can make sure it's going to be big enough, like, do we have enough land? Okay, yeah, we have enough land. Okay, let's dig a big hole and make sure we have enough room to pour this. Now let's pour this. There's these checking spots along the way to ensure that you're still delivering the right value. And then there's always the check-in of, like, have I delivered enough value? I don't need to finish everything.

Maybe we get to the point where we say, you know, feature number one was and is the aspirational goal for this mobile app or whatever. But it turns out that the sum of the value provided by features 2, 4, 6, and 9 actually are greater than 1. And we were able to do those in two months as opposed to two years. So let's figure that out. Small pieces, small changes.

MIKE: You've said a couple of things there, Jeff, that if you push out more than one thing, you don't know which one made a difference. And you also talked about 2.0. So I was thinking so 1.7.3.9 is actually important? [laughs] It sounds like yes. And you're saying a big part of the reason for that is that if you don't push out those features in isolation, then you can't evaluate them very well in isolation. Do I hear you right?

JEFF: Yeah. And I appreciate the 1.7.3.9, like, yeah, 100%. And I think that there's this big challenge. And, Mike, you've talked about the startup life. I am super fortunate. And I really love where I work because I work at a company that's a 30-year-old company. It's been under the same ownership group for 30 years. It's a business that's doing well. I mean, it survived the travel pandemic, you know, and all of that scare. So it's a stable company. It's got a long history. We're no longer trying to say, do I have product-market fit? Am I going to make it to next month? Am I going to make it to the next quarter?

They've survived this big recent scare that was an industry-wide scare for travel in general. But what they did is they took a hard look at what they've done, and they've said, oh man, we've missed the boat. We haven't created value for our users. And so, let's pause and hit the reset button. And so I'm fortunate that I get to work at the best-funded startup, right? Like, it's a really awesome opportunity for me. I'm excited.

And what it's proven is we have a lot of stuff that's actually on version 7.0. And what we realized is that everything from 5 to 6.9 didn't drive value. And so now we're going back and saying, do I really want to go to 8.0? Or do I just want to start over and say, here's MVP, here's 0.1? And I'm going to take another attempt at trying to solve your problem. And the reason why I'm bringing that up is because I think that there's this product maturity that happens over time. And there's a lot of conversation about a minimum viable product.

And, Dave, I think that's exactly what you're hitting on of, like, how do I truly define the minimum amount of work that I can do to create something that's viable? And that is really difficult. And I'm going to kind of challenge a little bit about what you said, Mike, of like, once a product's reached maturity, it is super important to isolate these changes. But, at some point, you have to find enough things. And maybe that's a couple of different features to go from 0 to 1 or 0 to 0.5.

I think it's a totally different mindset of I've got a mature product where I'm iterating through and optimizing, or I'm creating something that's brand new. How do I minimize the amount of work I need to do to make something brand new? And so I honestly don't know. We're in the middle of trying to figure this out as well.

Because I showed up and we were talking, you know, I started a year ago, actually, this month. And one of the first things they talked about is, like, hey, we've got this mobile app, and it's going to do these 17 things, and it's going to be awesome. The dev team's been working on it, and they're still working on it. And you know what? Sadly, we're still working on it because we weren't diligent enough about minimum. It's hard to go from zero to one.

And so, I would love to hear your feedback on how do you launch something that's brand new where you do need to have a collection of features? But it's got to be the right collection that's the least amount of effort that creates the most value. So, Mike, I agree. But I think there's this wrinkle in there that's new product creation; there are a few things that you do kind of need to bundle up, or you need to find out how to balance those.

MIKE: I'll bite on that a little bit. If you're doing a minimum viable product...I've heard a quote attributed to Steve Jobs. I haven't verified it, but I believe that it's correct. It says that if you're not embarrassed by your first release, you're doing it wrong. [laughs]

JEFF: Yeah, I think that's Reid Hoffman in LinkedIn, actually.

MIKE: It's an excellent idea that you need to tamp down your vision a little bit and be just vicious in determining what that minimum actually is. And think about anything you can possibly cut. Anything beyond that is risk. I'll say that it's risk because anything you add to the bundle is extra work that you put in that you haven't validated. So I think we need to be exceptionally willing to cut anything that could possibly not be truly minimum. That's one trick.

And there's also another trick that sometimes people use, and that's the word beta. [laughs] Sometimes you can release something that's not fully viable but provides some value in a niche to say, hey, you know what? We're launching this. And you find a subset of your users that are kind of the power users. And you say, you know what? We don't have everything that we need, but we're going to try this new thing. Would you like to have this extra feature? And there are a subset of your users that probably do. They would like to try out that new feature without having all of the things. They might like just one of the things.

And you work with that group, and you're actually giving them something, right? As long as you build it with quality, you're developing loyalty with your customers by giving a subset of your customers a more valuable experience. And in return for giving them that experience, you get feedback. You get some validation as to whether that product was valuable. There's my couple of thoughts and an answer to your question.

JEFF: I love the concept of, I'm going to call this what it is, and it's not done. [laughter] So you can be as mad as you want. I totally agree with you. But we've talked to 10 or 15 of you, and you think that there's value in it. And that idea of being embarrassed, I love that paired with the beta. Because you're saying I have done the bare minimum possible, but I told you that upfront. And you told me that you'd be willing to try, so please don't be mad at me. Please be nice to me. [laughs] Like, I don't need to be embarrassed because I already told you. I lead transparency in that engagement with your users and your customers.

I think that is truly where, you know, you get the user, a designer, a product person, and a developer. And I think that combination is where you create incredible value for people. I think about Airbnb when they launched and how they were like, okay, we don't know what to do, like, you're just going to go sleep on somebody's couch? Like, that's such a crazy idea.

That entire business concept was probably kind of embarrassing for people to just say, like, oh yeah, I'm just going to sleep on this person's couch over here, but then it caught on. And now it's this massive industry that's also spun out a whole new real estate empire of, like, I now own properties that I do Airbnb rent. Like, it's generated all this stuff.

So it may have been a little bit weird, a little bit different, but they owned it. And they said, yes, this is kind of interesting. It might not be for everybody, but there's somebody who would pay for this, and let me go talk to that person. And I'm just going to tell them, "It's not done, but we'd love to know how you would change this." [crosstalk 35:43] It's always easier, to be honest [laughs] and transparent than to try to hide stuff.

DAVID: There's an interesting idea that somebody pressed me on on Twitter or Mastodon or one of those social media things. We were talking about MVP. And there's this interesting notion that going from zero to one, you don't go from a 0.9.9 version, which is in-house, and you only show it to your team. You don't go directly from there to a nationwide release, to the open market, and loyal customers, and angry customers, and hostile competitors all using your product.

There's this idea that maybe the MVP goes to a much more sympathetic audience where, you know, we say, "Hey, this is beta. It should work no matter how you use it, but it's not going to, so let us know." Or you even say, "Hey, this is an alpha sketch of an idea. It probably won't work. But I think if you coax the software, [laughs] you can manipulate it and trick it into doing the thing that you want. Just be gentle with it. You can baby it. But it will let you book your travel, or it will let you order your Airbnb, or it will let you sign up for, you know, a lease in a completely new way."

And because you're showing that to somebody who's very sympathetic to you, who's very friendly to your company, they're like, "Oh yeah, I would love to see this." And then they know, oh yeah, I can't type that in there. It breaks the app. But if I do this and I do...wait, I can go from here to here? Holy crap, that's amazing. And you just validated your idea.

But you had to do it with somebody who was very sympathetic, and it was a very small release audience. And that's somebody that you can hand a 0.1 to, and you can tell them with a straight face, "I want you to try this and tell me your thoughts. It's probably not going to go into the final product. I just need to know if this one idea works or not."

JEFF: Yeah. Find your friends, your friendly customers.

DAVID: [laughs] I like it.

JEFF: Yeah.

DAVID: It's like Airbnb but for beta testers.

JEFF: [laughs]

DAVID: There's a business idea. This has been a fantastic discussion, Jeff. Thank you for coming. We lost Tyson partway through. Unfortunately, he's busy.

JEFF: Thank you. I appreciate it. It's been a blast being here. So it's been nice to come back and talk to everybody, hang out again.